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 pastes into the window under the pointer when an entry is clicked
Reported by rwilson131 · filed Sep 23, 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
Summary
Picking an entry in the clipboard manager (SUPER + CTRL + V, omarchy.clipboard) with the
mouse pastes it into whichever window is under the pointer, not the window the manager was
opened from. With tiled windows that is usually the tile behind the centered card.
Picking the same entry with the keyboard (arrows + Enter) pastes into the right window.
Environment
- Omarchy 4.0.4-1, Hyprland 0.56.2 (Lua config), stock
input:follow_mouse = 1 - Omarchy shell clipboard plugin as shipped (
shell/plugins/clipboard/Clipboard.qml)
Steps to reproduce
- Two tiled windows on one workspace, e.g. two terminals, left and right.
- Focus the right window. Press
SUPER + CTRL + V. - Click an entry on the card. The card is centered, so the pointer ends up over the left window.
- The entry is pasted into the left window, and the left window takes focus.
Expected: pasted into the right window (where the manager was opened), focus unchanged.
Evidence
Hyprland event socket during one reproduction (right window …5d30, left window …76f0):
21:00:51.450 openlayer>>omarchy-clipboard
21:00:54.150 closelayer>>omarchy-clipboard
21:00:54.151 activewindowv2>>564d90535d30 <- focus restored to the origin window
21:00:54.153 activewindowv2>>564d8f6e76f0 <- 2 ms later: window under the pointer
21:00:54.342 activelayout>>hl-virtual-keyboard-wtype <- Shift+Insert from omarchy-clipboard-paste-textThe pointer moved from the right window to x=722 (over the left tile) to click the entry.
Cause
applySelected() closes the overlay and runs omarchy-clipboard-paste-text /omarchy-clipboard-paste-file, which sleep 0.15 s and send Shift+Insert to the focused
window. When the exclusive-keyboard layer unmaps, Hyprland restores focus and thenfollow_mouse immediately refocuses the window under the pointer, so the synthetic paste
goes there.
This is the same root cause as the emoji picker's mouse-selection bug that #8573 fixes
(record the origin window in open(), refocus it before inserting). The clipboard manager
has no equivalent fix yet; searched open/closed issues and PRs for clipboard + focus/paste.
Suggested fix
Same shape as #8573:
Clipboard.qml: record the focused window's address inopen()(e.g.
Hyprland.activeToplevel, or hyprctl activewindow -j) and pass it to the paste helper.
- Paste helpers: after the overlay closes, refocus that address with
hl.dsp.focus({ window = 'address:<addr>' }), then send the paste.
Verified locally with a user clone of the plugin that does exactly this: with the pointer
parked over the other tile, pastes land in the origin window in both directions, and the
keyboard path is unchanged.
View raw text
## Summary
Picking an entry in the clipboard manager (`SUPER + CTRL + V`, `omarchy.clipboard`) with the
mouse pastes it into whichever window is under the pointer, not the window the manager was
opened from. With tiled windows that is usually the tile behind the centered card.
Picking the same entry with the keyboard (arrows + Enter) pastes into the right window.
## Environment
- Omarchy 4.0.4-1, Hyprland 0.56.2 (Lua config), stock `input:follow_mouse = 1`
- Omarchy shell clipboard plugin as shipped (`shell/plugins/clipboard/Clipboard.qml`)
## Steps to reproduce
1. Two tiled windows on one workspace, e.g. two terminals, left and right.
2. Focus the right window. Press `SUPER + CTRL + V`.
3. Click an entry on the card. The card is centered, so the pointer ends up over the left window.
4. The entry is pasted into the **left** window, and the left window takes focus.
Expected: pasted into the right window (where the manager was opened), focus unchanged.
## Evidence
Hyprland event socket during one reproduction (right window `…5d30`, left window `…76f0`):
```
21:00:51.450 openlayer>>omarchy-clipboard
21:00:54.150 closelayer>>omarchy-clipboard
21:00:54.151 activewindowv2>>564d90535d30 <- focus restored to the origin window
21:00:54.153 activewindowv2>>564d8f6e76f0 <- 2 ms later: window under the pointer
21:00:54.342 activelayout>>hl-virtual-keyboard-wtype <- Shift+Insert from omarchy-clipboard-paste-text
```
The pointer moved from the right window to x=722 (over the left tile) to click the entry.
## Cause
`applySelected()` closes the overlay and runs `omarchy-clipboard-paste-text` /
`omarchy-clipboard-paste-file`, which sleep 0.15 s and send `Shift+Insert` to the focused
window. When the exclusive-keyboard layer unmaps, Hyprland restores focus and then
`follow_mouse` immediately refocuses the window under the pointer, so the synthetic paste
goes there.
This is the same root cause as the emoji picker's mouse-selection bug that **#8573** fixes
(record the origin window in `open()`, refocus it before inserting). The clipboard manager
has no equivalent fix yet; searched open/closed issues and PRs for clipboard + focus/paste.
## Suggested fix
Same shape as #8573:
- `Clipboard.qml`: record the focused window's address in `open()` (e.g.
`Hyprland.activeToplevel`, or `hyprctl activewindow -j`) and pass it to the paste helper.
- Paste helpers: after the overlay closes, refocus that address with
`hl.dsp.focus({ window = 'address:<addr>' })`, then send the paste.
Verified locally with a user clone of the plugin that does exactly this: with the pointer
parked over the other tile, pastes land in the origin window in both directions, and the
keyboard path is unchanged.
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 17:33 UTC