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.
Clipboard manager never deletes image files: removed/cleared entries stay in clipboard-images/ and keep showing up in search
Reported by TonciZ · filed Oct 4, 2026 · open at source
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?
- AreaOutside the audited area· Decided by agents · verified
- 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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Intel i5-7600K, NVIDIA RTX 3060 Ti, Omarchy 4.0.4-1, Hyprland 0.56.2
What's wrong?
Removing an image entry from the clipboard manager (Super+Ctrl+V → Delete), or clearing the whole history (Shift+Delete), only rewrites ~/.local/state/omarchy/clipboard-history.json. The image file in ~/.local/state/omarchy/clipboard-images/ is never deleted. The same happens when old entries drop off the end of the 300-entry historyLimit.
So images the user deliberately deleted stay on disk with no limit. They also still appear in file search and the fuzzy finder, which is a privacy problem when a screenshot held something sensitive.
Steps
1. Copy an image, for example with a screenshot to the clipboard.
2. Open the clipboard manager, select the entry and press Delete (or Shift+Delete to clear all).
3. ls ~/.local/state/omarchy/clipboard-images/: the file is still there.
On my machine 32 orphaned images had built up while the history was empty.
Cause
In shell/plugins/clipboard/Clipboard.qml, removeDisplayIndex() and confirmClearHistory() only change the in-memory list and call saveHistory(). ClipboardHistory.addEntry() trims to the limit the same way. Nothing removes entry.path from disk.
Suggested fix
After saveHistory(), delete any file in clipboard-images/ that the history no longer references. As a local workaround I run that pruning step from a systemd .path unit watching the history JSON. It skips files under 30 seconds old, because capture.sh writes the image before the entry is added.
Related: #10769 (permissions on the same directory).
View raw text
### System details Intel i5-7600K, NVIDIA RTX 3060 Ti, Omarchy 4.0.4-1, Hyprland 0.56.2 ### What's wrong? Removing an image entry from the clipboard manager (Super+Ctrl+V → Delete), or clearing the whole history (Shift+Delete), only rewrites `~/.local/state/omarchy/clipboard-history.json`. The image file in `~/.local/state/omarchy/clipboard-images/` is never deleted. The same happens when old entries drop off the end of the 300-entry `historyLimit`. So images the user deliberately deleted stay on disk with no limit. They also still appear in file search and the fuzzy finder, which is a privacy problem when a screenshot held something sensitive. **Steps** 1. Copy an image, for example with a screenshot to the clipboard. 2. Open the clipboard manager, select the entry and press Delete (or Shift+Delete to clear all). 3. `ls ~/.local/state/omarchy/clipboard-images/`: the file is still there. On my machine 32 orphaned images had built up while the history was empty. **Cause** In `shell/plugins/clipboard/Clipboard.qml`, `removeDisplayIndex()` and `confirmClearHistory()` only change the in-memory list and call `saveHistory()`. `ClipboardHistory.addEntry()` trims to the limit the same way. Nothing removes `entry.path` from disk. **Suggested fix** After `saveHistory()`, delete any file in `clipboard-images/` that the history no longer references. As a local workaround I run that pruning step from a systemd `.path` unit watching the history JSON. It skips files under 30 seconds old, because `capture.sh` writes the image before the entry is added. Related: #10769 (permissions on the same directory).
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.
- Out of scopeDecided by agents · verified · 2026-10-09 21:20 UTC