Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
`wl-clip-persist` randomly fails to copy. Fix was to remove it.
Reported by pmercatoris · filed Aug 25, 2025Closed upstream on 2025-11-03 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
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..*
View raw text
### 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`): ```diff - exec-once = wl-clip-persist --clipboard regular ... + # exec-once = wl-clip-persist --clipboard regular ... ``` `cliphist` lines in ~/.config/hypr/autostart.conf were added: ```diff + 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..***
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.