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.
Bar popup panels can leave a stuck full-screen overlay that blocks input
Reported by M0VO · filed Sep 9, 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
System details
Omarchy 4.0.3-1 Hyprland 0.56.2 Quickshell 0.3.1-1 Arch Linux, kernel 7.2.3-arch1-3 Dual monitors: HP E233 + Dell AW2521HF CPU:Intel 11700K GPU: 4070TI 12GB
What's wrong?
Bar popup panels can leave a stuck full-screen overlay that blocks input
Component: Omarchy shell / Quickshell (KeyboardPanel)
Summary
Omarchy bar popups use a full-screen transparent overlay to detect clicks outside the panel.
If a popup is busy loading or processing something and I click outside it, the dismiss event sometimes doesn't get processed. The popup's invisible full-screen overlay remains active and blocks almost all mouse and keyboard input on that monitor.
Switching workspaces does not fix it. omarchy-shell <panel> close or toggle also return successfully but do nothing.
The only workaround I found is using:
Super + Shift + Escapeto restart/recover the shell.
This seems to affect different popup panels, but it is easier to trigger with plugins doing heavy or network-related work, such as Better Weather.
Steps to reproduce
- Open a bar popup (Wi-Fi, weather, audio, etc.).
- Trigger something that keeps it busy, such as loading network data.
- Click outside the popup.
Expected
The popup should close and stop intercepting input.
Actual
The outside click is swallowed, the popup remains stuck, and its invisible full-screen overlay blocks almost all input on that monitor. Switching workspaces does not remove the overlay.
While stuck, hyprctl layers shows a full-screen omarchy-keyboard-panel overlay:
Monitor DP-1:
Layer level 3 (overlay):
Layer ...: xywh: 1920 0 1920 1080, a: 1, namespace: omarchy-keyboard-panelPossible cause
KeyboardPanel.qml appears to rely on a QML MouseArea for outside-click dismissal. If the panel is busy, that event may not be processed while the full-screen overlay continues intercepting input.
Suggested fix
There should be a way to force-close the active popup and remove its input-blocking overlay independently of the plugin or panel state, for example:
omarchy-shell bar closeActivePopoutA busy plugin should never be able to leave a monitor effectively unusable.
Environment
- Omarchy 4.0.3-1
- Hyprland 0.56.2
- Quickshell 0.3.1-1
- Arch Linux, kernel 7.2.3-arch1-3
- Dual monitors: HP E233 + Dell AW2521HF
View raw text
### System details
Omarchy 4.0.3-1 _ Hyprland 0.56.2 _ Quickshell 0.3.1-1 _ Arch Linux, kernel 7.2.3-arch1-3 _ Dual monitors: HP E233 + Dell AW2521HF _ CPU:Intel 11700K _ GPU: 4070TI 12GB
### What's wrong?
# Bar popup panels can leave a stuck full-screen overlay that blocks input
**Component:** Omarchy shell / Quickshell (`KeyboardPanel`)
## Summary
Omarchy bar popups use a full-screen transparent overlay to detect clicks outside the panel.
If a popup is busy loading or processing something and I click outside it, the dismiss event sometimes doesn't get processed. The popup's invisible full-screen overlay remains active and blocks almost all mouse and keyboard input on that monitor.
Switching workspaces does not fix it. `omarchy-shell <panel> close` or `toggle` also return successfully but do nothing.
The only workaround I found is using:
```text
Super + Shift + Escape
```
to restart/recover the shell.
This seems to affect different popup panels, but it is easier to trigger with plugins doing heavy or network-related work, such as Better Weather.
## Steps to reproduce
1. Open a bar popup (Wi-Fi, weather, audio, etc.).
2. Trigger something that keeps it busy, such as loading network data.
3. Click outside the popup.
## Expected
The popup should close and stop intercepting input.
## Actual
The outside click is swallowed, the popup remains stuck, and its invisible full-screen overlay blocks almost all input on that monitor. Switching workspaces does not remove the overlay.
While stuck, `hyprctl layers` shows a full-screen `omarchy-keyboard-panel` overlay:
```text
Monitor DP-1:
Layer level 3 (overlay):
Layer ...: xywh: 1920 0 1920 1080, a: 1, namespace: omarchy-keyboard-panel
```
## Possible cause
`KeyboardPanel.qml` appears to rely on a QML `MouseArea` for outside-click dismissal. If the panel is busy, that event may not be processed while the full-screen overlay continues intercepting input.
## Suggested fix
There should be a way to force-close the active popup and remove its input-blocking overlay independently of the plugin or panel state, for example:
```text
omarchy-shell bar closeActivePopout
```
A busy plugin should never be able to leave a monitor effectively unusable.
## Environment
* Omarchy 4.0.3-1
* Hyprland 0.56.2
* Quickshell 0.3.1-1
* Arch Linux, kernel 7.2.3-arch1-3
* Dual monitors: HP E233 + Dell AW2521HF
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 11:22 UTC