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.
Zen Browser has weird mouse interraction
Reported by segersniels · filed Jun 8, 2026Closed upstream on 2026-06-08 by its own reporter segersniels. GitHub close reason: completed. Closed by its own reporter — not by itself 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
System details
AMD Ryzen AI Max 385 w/ Radeon 8050S — Omarchy v3.8.2-1-g8e031516
What's wrong?
Zen Browser seems to have broken mouse interactions on Omarchy/Hyprland.
- Hover states often do not show when moving the mouse over UI elements.
- Hover states sometimes only appear after clicking the element.
- Dragging tabs around in Zen's sidebar often tears the tab out into a new Zen window instead of reordering it.
Steps to reproduce:
1. Open Zen Browser
2. Move the mouse over browser UI elements that normally show hover styling
3. Notice that hover state often does not update until clicking
4. Drag a tab within Zen's sidebar to reorder it
5. Notice that the tab may be moved into a newly created Zen window instead of reordering normally
Expected behavior:
- Hover states should update immediately on mouse hover.
- Dragging tabs in the sidebar should reorder/move tabs predictably, not unexpectedly create a new window.
Additional context:
- I often access this Omarchy session remotely through Sunshine/Moonlight.
- I am not sure yet whether the issue happens only through Moonlight input forwarding or also with locally connected mouse/keyboard.
- Other apps seem to behave normally in the same session, so Zen is the only app where I have noticed this mouse interaction problem.
View raw text
### System details AMD Ryzen AI Max 385 w/ Radeon 8050S — Omarchy v3.8.2-1-g8e031516 ### What's wrong? **Zen Browser** seems to have broken mouse interactions on Omarchy/Hyprland. - Hover states often do not show when moving the mouse over UI elements. - Hover states sometimes only appear after clicking the element. - Dragging tabs around in Zen's sidebar often tears the tab out into a new Zen window instead of reordering it. Steps to reproduce: 1. Open Zen Browser 2. Move the mouse over browser UI elements that normally show hover styling 3. Notice that hover state often does not update until clicking 4. Drag a tab within Zen's sidebar to reorder it 5. Notice that the tab may be moved into a newly created Zen window instead of reordering normally Expected behavior: - Hover states should update immediately on mouse hover. - Dragging tabs in the sidebar should reorder/move tabs predictably, not unexpectedly create a new window. Additional context: - I often access this Omarchy session remotely through Sunshine/Moonlight. - I am not sure yet whether the issue happens only through Moonlight input forwarding or also with locally connected mouse/keyboard. - Other apps seem to behave normally in the same session, so Zen is the only app where I have noticed this mouse interaction problem. [omarchy-debug.log](https://github.com/user-attachments/files/28705044/omarchy-debug.log)
- omarchy-debug.log
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.