Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1299GitHub issuePublicDecided· Out of scope

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.

Decided: Out of scope — decided by agents · verified 4 days ago.

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

Focus gets stuck on one window at random - until i unstuck it with a workspace switch with touchpadrevision 1 · captured 2026-09-28 21:24 UTC via poll

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