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.
Empty scratchpad forwards keyboard input to the underlying window
Reported by JoNil · filed Aug 31, 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
What's wrong?
When the scratchpad is shown while it contains no windows, keyboard input can still be delivered to the tiled window underneath it. For example, pressing Escape affects the underlying application while the empty scratchpad remains visible.
Steps to reproduce
- Make sure
special:scratchpadcontains no windows. - Focus a tiled application that reacts visibly to
Escape. - Press
Super + Sto show the scratchpad. - Press
Escape. - Observe that the underlying tiled application receives the key and the empty scratchpad remains shown.
Expected behavior
When the scratchpad is empty and visible, pressing Escape should dismiss it instead of being forwarded to the underlying tiled window.
This behavior should be limited to the empty state. If the scratchpad contains a focused window, Escape should continue to be delivered normally to that window.
More generally, showing an empty scratchpad should not cause keyboard input to interact unexpectedly with an obscured underlying window.
Possibly relevant
The stock Super + S binding directly invokes hl.dsp.workspace.toggle_special("scratchpad"). There does not appear to be any empty-state input handling that can intercept Escape and hide the special workspace.
View raw text
### What's wrong?
When the scratchpad is shown while it contains no windows, keyboard input can still be delivered to the tiled window underneath it. For example, pressing `Escape` affects the underlying application while the empty scratchpad remains visible.
### Steps to reproduce
1. Make sure `special:scratchpad` contains no windows.
2. Focus a tiled application that reacts visibly to `Escape`.
3. Press `Super + S` to show the scratchpad.
4. Press `Escape`.
5. Observe that the underlying tiled application receives the key and the empty scratchpad remains shown.
### Expected behavior
When the scratchpad is empty and visible, pressing `Escape` should dismiss it instead of being forwarded to the underlying tiled window.
This behavior should be limited to the empty state. If the scratchpad contains a focused window, `Escape` should continue to be delivered normally to that window.
More generally, showing an empty scratchpad should not cause keyboard input to interact unexpectedly with an obscured underlying window.
### Possibly relevant
The stock `Super + S` binding directly invokes `hl.dsp.workspace.toggle_special("scratchpad")`. There does not appear to be any empty-state input handling that can intercept `Escape` and hide the special workspace.
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 10:20 UTC