`wl-clip-persist` randomly fails to copy. Fix was to remove it.

[pmercatoris]

Issue Summary

The default Omarchy Hyprland configuration starts two conflicting clipboard services: wl-clip-persist and a clipboard notifier launched by the walker daemon. This conflict results in a non-functional clipboard, especially for XWayland applications, requiring manual user intervention to fix.

The Problem I Was Facing

On a fresh installation, I was unable to copy from an XWayland application (Emacs) and paste into a Wayland terminal (wl-paste was empty). This occurred even though all applications were correctly configured. Diagnostic steps revealed that two different clipboard management processes were being launched by default at startup, causing a conflict.

Root Cause Analysis

The default Omarchy configuration starts two clipboard-related services from different files:

Service 1: The Persistence Daemon. A command like exec-once = wl-clip-persist ... is sourced, which actively takes ownership of the clipboard content to make it persistent.

Service 2: The Notifier Daemon. The ~/.local/share/omarchy/defaut/hypr/autostart.conf file launches the walker service via exec-once = uwsm app -- walker --gapplication-service. This walker process, in turn, launches its own clipboard watcher (wl-paste --watch kill...).

These two services conflict with each other, leading to a race condition where neither can reliably manage the clipboard. The default configuration is internally inconsistent.

The Fix

The issue was resolved by disabling one of the conflicting default services (wl-clip-persist) and enabling a known-working alternative (cliphist) that does not conflict with the walker notifier.

The following changes were made in the configuration files:

The default wl-clip-persist daemon was disabled (e.g., by commenting it out in ~/.local/share/omarchy/defaut/hypr/autostart.conf):

- exec-once = wl-clip-persist --clipboard regular ...
+ # exec-once = wl-clip-persist --clipboard regular ...

cliphist lines in ~/.config/hypr/autostart.conf were added:

+ exec-once = wl-paste --type text --watch cliphist store &
+ exec-once = wl-paste --type image --watch cliphist store &

After a reboot, this new combination (walker's notifier + cliphist's history manager) works correctly, whereas the default configuration did not.

Recommendation and Benefit

The default Omarchy configuration is broken because it starts two conflicting clipboard services.

I recommend that the default configuration be simplified to use only one, non-conflicting clipboard manager. Enabling the cliphist lines by default and removing the wl-clip-persist and walker service lines from the default configuration would provide the best experience.

The benefit of this change is a stable and feature-rich clipboard that works out of the box. It would provide users with clipboard history by default and, most importantly, eliminate the need for them to manually troubleshoot a fundamental desktop function.

This issue was generated from troubleshooting with gemini, hope it all makes sense..

[abenz1267]

You are confusing a few things here:

• Walker has no notifier => it just stores clipboard history
• ... which you now do twice?!

wl-clip-persist does not store clipboard history, it just makes the clipboard content stay after the copied-from-application has been closed.

Ideally you'd only need Walker.

[abenz1267]

I've actually just tested this with emacs and foot .. copy pasting from emacs to foot worked fine with wl-clip-persist & walker (latest walker.. not the one omarchy ships atm).

[abenz1267]

after a reboot i had issues with copying from f.e. neovim. dunno.... it seems like wl-clip-persist is wonky?

i'll look into making elephant persist clipboard content at some point....

[pmercatoris]

I thought I understood the problem/fix by using gemini to troubleshoot, but it seems to be a different problem. I thought my fix worked, but it the problem seems to reappear here as well. As you said it, the behavior is wonky..

[abenz1267]

AI strikes again.

[pmercatoris]

Ok, it didn't work because of the Omarchy update that undid the comment of wl-clip-persist. The only way to have the clipboard to properly work is to comment it and use cliphist instead, just as commented in my first comment.

[abenz1267]

you still misunderstand that cliphist and wl-clip-persist dont do the same thing.

[pmercatoris]

I am going to try to rephrase.

The issue that i am encountering is that I cannot copy from emacs xwayland to other applications like chromium or alacritty. I would copy from emacs, and when pasting to other applications it would be empty. From other applications to emacs, it wouldn't be a problem and from alacritty to chromium it would also work as expected.

Now through using Gemini to debug, i have seen this:

~ ❯ ps aux | grep 'wl-clip-persist\|wl-paste'

pmercat+    2424  0.0  0.0  74552  5148 ?        Sl   13:12   0:00 wl-clip-persist --clipboard regular --all-mime-type-regex ^(?!x-kde-passwordManagerHint).+

pmercat+    2545  0.0  0.0   2840  1824 ?        S    13:12   0:00 wl-paste --watch kill -USR1 2420

pmercat+    4123  0.0  0.0   6864  4464 pts/0    S+   13:14   0:00 grep --color=auto wl-clip-persist\|wl-paste

Which Gemini diagnosed as

The wl-paste command was spawned by walker:

~ ✗ pstree -sp $(pgrep -f "wl-paste --watch kill")

systemd(1)───systemd(1953)───walker(2420)───wl-paste(2545)

Now, as cliphist is basically managing the whole history. Gemini was guiding me more towards disabling wl-clip-persist. I understand that wl-clip-persist might be less bloated, and i don't really care too much for the clipboard history. More that importantly i am looking to be able to copy reliably from emacs.

What i found, was that disabling wl-clip-persist and enabling cliphist, this behavior has been fixed, and i can now reliably copy from emacs to any other application.

Sorry for the confusion, i just thought it would be interesting to comment on it, as it seems that the default configuration might overlook that usecase. And as I understand, you also encountered that issue of not reliably being able to copy?

[abenz1267]

Gemini is talking 100% shit.

This has nothing to do with bloat or whatever, i'll explain it again:

• wl-clip-persist: makes you that your copied content PERSISTS in the clipboard, even after you CLOSE the copied-from application => by default wayland DISCARDS the clipboard otherwise
• cliphist/walker: just SAVE the clipboard content for history access

those programs do DIFFERENT THINGS. again: gemini is talking utter shit.

wl-clip-persist and wl-clipboard ARE NOT EXCHANGABLE.

installing cliphist is NOT needed when using walker.

[pmercatoris]

Ok, thanks! so I might have gone wrong by installing wl-clipboard, cliphist etc? Obviously i went through to install it because i encountered the problem, but I am going to try and see if with a fresh install on my laptop, I keep getting the issue and report back.

Thanks for getting back to me :)

[abenz1267]

wl-clipboard is required. cliphist => not if using walker.

[pmercatoris]

while installing a fresh on my laptop with the new iso, i tested on my main computer.

i removed cliphist and reenabled wl-clip-persist.

After reboot, i get the same behaviour as before my "fix".

But I am realising that the it is just wonky, as you said earlier. If i copy some text from emacs and try to paste it directly into chromium, it might not work straight away. and wl-paste into the terminal would not return anything. Now, i wait a few seconds, wl-paste shows the content without copying again.

~ ❯ wl-paste


~ ❯ wl-paste --list-types
MULTIPLE
text/plain
COMPOUND_TEXT
STRING
text/plain;charset=utf-8
text/plain
text/plain;charset=utf-8
LENGTH
DELETE
FILE_NAME
CHARACTER_POSITION
LINE_NUMBER
COLUMN_NUMBER
OWNER_OS
HOST_NAME
USER
CLASS
NAME
ATOM
INTEGER
SAVE_TARGETS

~ ❯ wl-paste
copy from emac
aljfa

~ ❯

Copying from chromium into emacs would always work first try.

[abenz1267]

it's wl-clip-persist that's doing the wonky here. Personally i don't have wl-clip-persist installed as i've honestly never copied something, closed the window and pasted it somewhere.

[pmercatoris]

I see, and probably don't really have that usecase.. I'm gonna try uninstalling it as well to see if that solves it.

[pmercatoris]

yea, removing it fixes it. Thanks, for the help! Indeed, Gemini just made me go full circle...

Now, do you think we should escalate this somewhere?

[abenz1267]

can't say... tbh i think wl-clip-persist is rather dead? Note sure. But i'd def. not install it by default, if it causes issues.

https://github.com/Linus789/wl-clip-persist/issues

Personally I'd like to implement clipboard persistence into walker/elephant itself to make wl-clip-persist redundant. But that's up in the stars for now.

[pmercatoris]

can't say... tbh i think wl-clip-persist is rather dead? Note sure. But i'd def. not install it by default, if it causes issues.

https://github.com/Linus789/wl-clip-persist/issues

Personally I'd like to implement clipboard persistence into walker/elephant itself to make wl-clip-persist redundant. But that's up in the stars for now.

@dhh what is your opinion on the matter?

[zaneschepke]

This is related to https://github.com/basecamp/omarchy/issues/35 as well. I have experienced this same issue with wl-clip-persist crashing apps since using Omarchy. For a better out of the box experience, it might be best to remove wl-clip-persist from Omarchy.

It might be worth updating the title of this issue to reflect the real issue @pmercatoris.

[pmercatoris]

Thanks @zaneschepke , I updated the title.

[zaneschepke]

I still have pasting crashing apps even with wl-clip-persist uninstalled. Anyone else?

[dhh]

We currently don't run the Walker service, but we will again after upgrading to Walker 1.0. But wl-clip-persist exists to store clipboard history from applications that you quit. Without this, that clipboard history is lost with cliphist.

@abenz1267 Does the Walker 1.0 clipboard service also capture clipboard history from apps that are closed so we don't need wl-clip-persist?

[abenz1267]

Clipboard content will be saved to the clipboard history as soon as it gets copied. But wl-clip-persists solves a different issue, as you said.

Even if walker has the content saved => close application => cant paste. You'd have to actively copy again from the walker clipboard.

wl-clip-persist is yet another pretty unmaintained thing that just doesnt work correctly.

[dhh]

Any appetite for pulling the persist part into the Walker clipboard manager? Would love to drop all of it and just lean on Walker for this!

[abenz1267]

Any appetite for pulling the persist part into the Walker clipboard manager? Would love to drop all of it and just lean on Walker for this!

Oh god, yes. Big time. I'm waiting for an upstream bugfix. Once that's fixed, i'll look into it. Potentially even making wl-clipboard obsolete.

[spdawson]

Verified that removing/disabling wl-clip-persist fixes broken copy/paste between Emacs and other applications; in my case, Emacs is not running under xwayland.

[KidDogDad]

Verifying that commenting out the wl-clip-persist line fixed a similar Emacs issue for me. In my case, I'm running emacs-wayland, and I could not paste anything I copied from other applications into Emacs; instead Emacs would paste the last thing I had copied from inside Emacs. This has been driving me crazy. Really appreciate you all figuring out the fix for this.

[spdawson]

I have also noticed that the Slack application (whether installed via slack-desktop or slack-desktop-wayland) is unstable when wl-clip-persist is running; the app will be reported as "not responding" seemingly at random; sometimes it will recover after a period of inactivity, and sometimes it will need to be killed.

With wl-clip-persist removed/disabled for a couple of days, so far I have not seen the Slack application hang. After re-enabling wl-clip-persist, Slack hung after only a few minutes.

I assume this may not be specific to the Slack application, and perhaps other Electron-based apps will be similarly unstable. Possibly related issue here: https://github.com/Linus789/wl-clip-persist/issues/16

[felipe-linares]

I have also noticed that the Slack application (whether installed via slack-desktop or slack-desktop-wayland) is unstable when wl-clip-persist is running; the app will be reported as "not responding" seemingly at random; sometimes it will recover after a period of inactivity, and sometimes it will need to be killed.

With wl-clip-persist removed/disabled for a couple of days, so far I have not seen the Slack application hang. After re-enabling wl-clip-persist, Slack hung after only a few minutes.

I assume this may not be specific to the Slack application, and perhaps other Electron-based apps will be similarly unstable. Possibly related issue here: Linus789/wl-clip-persist#16

I'm not sure if related but I found that sometimes wl-paste will completely stop working when pasting from XWayland apps and it'll cause whatever app I'm pasting into to just completely freeze and have to be force closed.

e.g. Copy big response string from Charles Proxy XWayland app, try to paste into neovim/slack/whatever -> the target app freezes.

Coincidentally whenever I have one of these "copies" saved in my clipboard from an XWayland app that has "stopped working," Slack will fail to launch until I clear my clipboard.

Slack must be trying to access the clipboard I guess on launch and since that "copy" in my clipboard history from the XWayland app is "broken" it will just freeze Slack entirely.

I'm just speculating and could be completely wrong but thought I'd add share my experience in case it helps debug this a bit. Happy to help debug this however possible.

[felipe-linares]

https://github.com/Linus789/wl-clip-persist/issues/22

Seems it may be fixed in upcoming wl-clip-persist release thanks to an in-depth bug report by another Omarchy user 😄

[mlabbe]

wl-clip-persist 0.5.0, which works around this problem, is now in arch packages extra. So you can run the Omarchy update and the hangs will go away.