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.
Emoji picker inserts into the wrong window when the card spans two windows
Reported by Guts444 · filed Aug 18, 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?
- 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. So far: in the audited area (menu) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
System details
AMD Ryzen 5 5600X (6 cores/12 threads), NVIDIA GTX 1660 SUPER, Omarchy 4.0.0 (quattro), single 1920x1080 display, two windows tiled side by side (also reproduces with two monitors side by side)
What's wrong?
The emoji picker (omarchy.emojis) inserts the picked emoji into the wrong window when the picker card visually spans two windows.
Steps to reproduce:
1. Open two windows side by side (e.g. a chat app on the left, a browser on the right), focus the left one.
2. Launch the emoji picker (Super+Ctrl+E or however it is bound). The card opens centered on the screen — i.e. its right half sits over the right window.
3. Click an emoji whose cell is on the right half of the card (visually over the right window).
Expected: the emoji is typed into the window that was focused when the picker opened (the left one).
Actual: the compositor refocuses the window under the clicked cell after the overlay closes, and omarchy-menu-emoji-insert pastes via wtype Shift+Insert into that window instead — e.g. into the browser's address bar. Emojis on the half of the card over the active window work fine, which makes the behavior look position-dependent.
Root cause: shell/plugins/emojis/Emojis.qml's applySelected() dismisses the overlay and then runs bin/omarchy-menu-emoji-insert, which pastes into whatever window is focused at that moment. With the overlay gone, focus has already been handed to the window under the cursor (the clicked cell's position), not the window the user was typing in.
A local fix (clone of the plugin with focus capture/restore) has been verified on this machine; a proper upstream patch is being prepared.
View raw text
### System details AMD Ryzen 5 5600X (6 cores/12 threads), NVIDIA GTX 1660 SUPER, Omarchy 4.0.0 (quattro), single 1920x1080 display, two windows tiled side by side (also reproduces with two monitors side by side) ### What's wrong? The emoji picker (omarchy.emojis) inserts the picked emoji into the **wrong window** when the picker card visually spans two windows. **Steps to reproduce:** 1. Open two windows side by side (e.g. a chat app on the left, a browser on the right), focus the left one. 2. Launch the emoji picker (`Super+Ctrl+E` or however it is bound). The card opens centered on the screen — i.e. its right half sits over the right window. 3. Click an emoji whose cell is on the **right half** of the card (visually over the right window). **Expected:** the emoji is typed into the window that was focused when the picker opened (the left one). **Actual:** the compositor refocuses the window under the clicked cell after the overlay closes, and `omarchy-menu-emoji-insert` pastes via `wtype Shift+Insert` into that window instead — e.g. into the browser's address bar. Emojis on the half of the card over the active window work fine, which makes the behavior look position-dependent. **Root cause:** `shell/plugins/emojis/Emojis.qml`'s `applySelected()` dismisses the overlay and then runs `bin/omarchy-menu-emoji-insert`, which pastes into whatever window is focused at that moment. With the overlay gone, focus has already been handed to the window under the cursor (the clicked cell's position), not the window the user was typing in. A local fix (clone of the plugin with focus capture/restore) has been verified on this machine; a proper upstream patch is being prepared.
Also reported as
R-1697 is the earliest report of this defect, filed Aug 18, 2026. 2 later reports describe the same defect.
Upstream consolidates it in R-1697 (other reports were closed there as its duplicates).
- Aug 18, 2026R-1697 · this report— the original
- ·Decided by agents · verified
Open upstream.
- ·Decided by agents · verified
Closed upstream on 2026-10-11 by the bot omarchybot, as a duplicate of #7350 (R-1697). GitHub close reason: duplicate.
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
- Fixed bypr/8573· confirmed
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.
- Decided by agents · verified: in the audited area (menu)
- Decided by agents · verified: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.