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.
Focus gets stuck on one window at random - until i unstuck it with a workspace switch with touchpad
Reported by jamers99 · filed Aug 28, 2026Closed upstream on 2026-10-09 by its own reporter jamers99. 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?
- 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
Surface Laptop Studio 2 — Intel Core i7-13700H, Intel Iris Xe + NVIDIA RTX 4050 Mobile, 3 displays (2400x1600 @ 1.6 scale + 2x 1920x1080), Omarchy 4.0.1, Hyprland 0.56.2, kernel 6.19.8-arch1-3-surface
What's wrong?
A few times a day, focus gets stuck on one window and I can't get out of it with the mouse.
When it happens:
- Moving the mouse over another window does nothing. The highlight border stays on the stuck window.
- Clicking another window does nothing. I can't interact with it at all.
- The mouse cursor itself moves around normally, across every window and all three monitors. It is not frozen or trapped.
- The keyboard still works. Alt+Tab moves focus to another window just fine, but the moment I move the mouse, focus jumps straight back to the stuck window.
- The stuck window itself keeps working normally.
To get out of it, I switch to another workspace and come back (using the 3-finger swipe gesture). That always works. Super+space then escape and the screensaver also clears it.
I have not found a way to reproduce... It happens several times a day at what feels like random moments. I've had it get stuck on a Chromium window, on Teams (Electron), and on a plain foot terminal, so it doesn't seem to be one particular app.
Extra digging (from Claude), in case it helps
I (Claude) checked with a script that records the mouse position and the focused window
while I move the mouse around. It confirmed the focus really is stuck rather
than just looking stuck: in one run, 34 out of 34 samples had the pointer over
a different window than the focused one.
Does not clear it: omarchy-restart-shell, hyprctl reload, pressing
Escape, or toggling the stuck window fullscreen and back.
Does clear it: switching workspace and back, or locking the screen. Both of
those hide the stuck window. Simply moving focus with a dispatcher does not
help, which makes me think something stays pinned to that window's surface
until it stops being displayed.
Things I was able to rule out:
- Not a stuck mouse button. I injected real button releases through
ydotool/uinput while it was stuck and nothing changed, and the kernel
reported no button held.
- Not a stuck key or modifier. hl.is_key_down reported nothing held.
- Not a leftover layer surface. hyprctl layers showed nothing in the overlay
layer while it was stuck.
- Not app specific (see above).
_This may well be a Hyprland bug rather than an Omarchy one. Happy to move it
there if that's the better place._
omarchy-debug not while stuck: omarchy-debug.log
UPDATE: omarchy-debug while stuck: omarchy-debug.log
View raw text
### System details Surface Laptop Studio 2 — Intel Core i7-13700H, Intel Iris Xe + NVIDIA RTX 4050 Mobile, 3 displays (2400x1600 @ 1.6 scale + 2x 1920x1080), Omarchy 4.0.1, Hyprland 0.56.2, kernel 6.19.8-arch1-3-surface ### What's wrong? A few times a day, focus gets stuck on one window and I can't get out of it with the mouse. When it happens: - Moving the mouse over another window does nothing. The highlight border stays on the stuck window. - Clicking another window does nothing. I can't interact with it at all. - The mouse cursor itself moves around normally, across every window and all three monitors. It is not frozen or trapped. - The keyboard still works. [Alt+Tab](https://omarchyplugins.com/plugin.html?id=io.github.pablo-merino.altswitch) moves focus to another window just fine, but the moment I move the mouse, focus jumps straight back to the stuck window. - The stuck window itself keeps working normally. To get out of it, I switch to another workspace and come back (using the 3-finger swipe gesture). That always works. Super+space then escape and the screensaver also clears it. **I have not found a way to reproduce...** It happens several times a day at what feels like random moments. I've had it get stuck on a Chromium window, on Teams (Electron), and on a plain foot terminal, so it doesn't seem to be one particular app. <details> <summary>Extra digging (from Claude), in case it helps</summary> I (Claude) checked with a script that records the mouse position and the focused window while I move the mouse around. It confirmed the focus really is stuck rather than just looking stuck: in one run, 34 out of 34 samples had the pointer over a different window than the focused one. Does **not** clear it: `omarchy-restart-shell`, `hyprctl reload`, pressing Escape, or toggling the stuck window fullscreen and back. Does clear it: switching workspace and back, or locking the screen. Both of those hide the stuck window. Simply moving focus with a dispatcher does not help, which makes me think something stays pinned to that window's surface until it stops being displayed. Things I was able to rule out: - Not a stuck mouse button. I injected real button releases through ydotool/uinput while it was stuck and nothing changed, and the kernel reported no button held. - Not a stuck key or modifier. `hl.is_key_down` reported nothing held. - Not a leftover layer surface. `hyprctl layers` showed nothing in the overlay layer while it was stuck. - Not app specific (see above). </details> _This may well be a Hyprland bug rather than an Omarchy one. Happy to move it there if that's the better place._ `omarchy-debug` **not** while stuck: [omarchy-debug.log](https://github.com/user-attachments/files/31564314/omarchy-debug.log) UPDATE: `omarchy-debug` while stuck: [omarchy-debug.log](https://github.com/user-attachments/files/31564404/omarchy-debug.log)
- 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.
- Out of scopeDecided by agents · verified · 2026-10-09 09:48 UTC