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.
`omarchy-cmd-screenshot`: hitting Print Screen occasionally locks input — Esc/clicks dead, cursor still moves
Reported by joshualambert · filed Apr 27, 2026Closed upstream on 2026-07-18 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not 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?
- Not yet mapped to any requirement or component.
- 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. No decision has been recorded yet.
Original report
Symptom
Pressing PRINT occasionally leaves the session in a state where:
- Cursor still moves
- Audio (e.g. an active Zoom / Teams-for-linux call) keeps playing fine
- All windows look frozen
- Clicks register nowhere
Escdoes not dismiss slurp- Hitting
PRINTagain does not trigger thepkill slurp && exit 0toggle at the top of the script
Only escape is Ctrl+Alt+F2 → pkill slurp hyprpicker → Ctrl+Alt+F1.
Hypothesis
omarchy-cmd-screenshot runs hyprpicker -r -z as a freeze layer in the background while slurp blocks for a region. hyprpicker -z paints its frozen snapshot on the overlay layer (level 3), which sits above slurp's top layer (level 2). When that overlay grabs keyboard focus first, slurp never sees Esc, and the script stays blocked on SELECTION=$(slurp) indefinitely. The compositor isn't dead — only the input route to slurp is. Audio is independent of the compositor, which matches.
Repro
Intermittent. Happens more often with another app holding screen-capture state (e.g. Zoom or Teams-for-linux in a call). Single- and dual-monitor both seen.
Workaround
Replaced the binding locally with a copy of omarchy-cmd-screenshot that drops hyprpicker -r -z entirely. Region selection is just slurp; the screen "lives" during selection but the deadlock path is gone. Reporting back after a week of soak.
Related
- #1564 — region screenshot broke with
--freeze(different stack, same "freeze layer breaks selection" pattern) - #5001 — current
hyprpicker -zdoesn't reliably freeze captured frames - v3.0.0 release notes:
--freezeremoved from hyprshot for being unstable - v3.4.0: switched wayfreeze → hyprpicker for HDR
System
- Omarchy 3.5.1
- Hyprland 0.54.3-2
- hyprpicker 0.4.6-3
- slurp 1.5.0-2 / grim 1.5.0-2 / satty 0.20.1-2
- xdg-desktop-portal-hyprland 1.3.11-4
- Monitors: 2× 2560×1440, scale 1.25, transform 0
View raw text
### Symptom Pressing `PRINT` occasionally leaves the session in a state where: - Cursor still moves - Audio (e.g. an active Zoom / Teams-for-linux call) keeps playing fine - All windows *look* frozen - Clicks register nowhere - `Esc` does **not** dismiss slurp - Hitting `PRINT` again does **not** trigger the `pkill slurp && exit 0` toggle at the top of the script Only escape is `Ctrl+Alt+F2` → `pkill slurp hyprpicker` → `Ctrl+Alt+F1`. ### Hypothesis `omarchy-cmd-screenshot` runs `hyprpicker -r -z` as a freeze layer in the background while `slurp` blocks for a region. `hyprpicker -z` paints its frozen snapshot on the **overlay** layer (level 3), which sits above slurp's **top** layer (level 2). When that overlay grabs keyboard focus first, slurp never sees `Esc`, and the script stays blocked on `SELECTION=$(slurp)` indefinitely. The compositor isn't dead — only the input route to slurp is. Audio is independent of the compositor, which matches. ### Repro Intermittent. Happens more often with another app holding screen-capture state (e.g. Zoom or Teams-for-linux in a call). Single- and dual-monitor both seen. ### Workaround Replaced the binding locally with a copy of `omarchy-cmd-screenshot` that drops `hyprpicker -r -z` entirely. Region selection is just slurp; the screen "lives" during selection but the deadlock path is gone. Reporting back after a week of soak. ### Related - #1564 — region screenshot broke with `--freeze` (different stack, same "freeze layer breaks selection" pattern) - #5001 — current `hyprpicker -z` doesn't reliably freeze captured frames - v3.0.0 release notes: `--freeze` removed from hyprshot for being unstable - v3.4.0: switched wayfreeze → hyprpicker for HDR ### System - Omarchy 3.5.1 - Hyprland 0.54.3-2 - hyprpicker 0.4.6-3 - slurp 1.5.0-2 / grim 1.5.0-2 / satty 0.20.1-2 - xdg-desktop-portal-hyprland 1.3.11-4 - Monitors: 2× 2560×1440, scale 1.25, transform 0
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.
No decision has been recorded yet.