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.
Menu (Super+Space) needs several presses to open after focus moves to another monitor
Reported by ctarx · filed Sep 28, 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
What happens
On a two-monitor setup, when I move focus to the other monitor and press Super+Space, the menu doesn't open on the first press. I have to press it several times before it shows up. When I stay on the same monitor, one press opens it every time.
This began after updating from r2304 to r6663 today, which pulled in #13419.
Expected
One Super+Space press opens the menu on the focused monitor, whichever monitor had the menu last.
Steps to reproduce
- Two monitors, both at scale 1.
- Open the menu with Super+Space on monitor A, then close it.
- Move focus to monitor B.
- Press Super+Space. The menu doesn't open. It only appears after one or more further presses.
Likely cause
#13419 introduced shell/Ui/OverlayWindow.qml. The overlay surface now persists between opens, parked as 1x1 on whichever screen it last used. It only switches screens when it is shown:
onShownChanged: if (shown) targetScreen = focusedScreen() || targetScreen
...
screen: targetScreenOn a PanelWindow, changing screen destroys the layer surface and creates a new one on the other output. Here that recreation happens during the same transition that sets shown to true, which raises the surface to the overlay layer and grants exclusive keyboard focus. On a different monitor, then, the first open lands on a surface being recreated. My guess is that the menu's opened state and the surface fall out of sync, so the next toggle() (shell.qml, isPluginOpen → hide) closes a menu that was never visible. Same-monitor opens don't change screen, which fits them working.
omarchy-menu toggle root takes the same shell.toggle path, so rebinding Super+Space to the command instead of the global shortcut doesn't help.
Possible direction: move the parked surface to the focused screen whenever the focused monitor changes, instead of doing it in the same step as showing it. Alternatively, wait for the recreated surface before setting shown.
Nothing relevant shows up in the Quickshell log.
System
- Omarchy 4.0.0.r6663.g3faafba-1
- quickshell 0.3.1-1, hyprland 0.56.2-3
- CPU: AMD Ryzen 7 3700X
- GPU: AMD Radeon RX 5700 XT (Navi 10)
- Monitors: DP-1 2560x1440 (scale 1), DP-2 1920x1080 (scale 1)
View raw text
## What happens On a two-monitor setup, when I move focus to the other monitor and press Super+Space, the menu doesn't open on the first press. I have to press it several times before it shows up. When I stay on the same monitor, one press opens it every time. This began after updating from r2304 to r6663 today, which pulled in #13419. ## Expected One Super+Space press opens the menu on the focused monitor, whichever monitor had the menu last. ## Steps to reproduce 1. Two monitors, both at scale 1. 2. Open the menu with Super+Space on monitor A, then close it. 3. Move focus to monitor B. 4. Press Super+Space. The menu doesn't open. It only appears after one or more further presses. ## Likely cause #13419 introduced `shell/Ui/OverlayWindow.qml`. The overlay surface now persists between opens, parked as 1x1 on whichever screen it last used. It only switches screens when it is shown: ```qml onShownChanged: if (shown) targetScreen = focusedScreen() || targetScreen ... screen: targetScreen ``` On a PanelWindow, changing `screen` destroys the layer surface and creates a new one on the other output. Here that recreation happens during the same transition that sets `shown` to true, which raises the surface to the overlay layer and grants exclusive keyboard focus. On a different monitor, then, the first open lands on a surface being recreated. My guess is that the menu's `opened` state and the surface fall out of sync, so the next `toggle()` (`shell.qml`, `isPluginOpen` → `hide`) closes a menu that was never visible. Same-monitor opens don't change `screen`, which fits them working. `omarchy-menu toggle root` takes the same `shell.toggle` path, so rebinding Super+Space to the command instead of the global shortcut doesn't help. Possible direction: move the parked surface to the focused screen whenever the focused monitor changes, instead of doing it in the same step as showing it. Alternatively, wait for the recreated surface before setting `shown`. Nothing relevant shows up in the Quickshell log. ## System - Omarchy 4.0.0.r6663.g3faafba-1 - quickshell 0.3.1-1, hyprland 0.56.2-3 - CPU: AMD Ryzen 7 3700X - GPU: AMD Radeon RX 5700 XT (Navi 10) - Monitors: DP-1 2560x1440 (scale 1), DP-2 1920x1080 (scale 1)
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
- Related PRpr/13792· confirmed
- Fixed bypr/13809· confirmed
- Fixed bypr/13903· 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.