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.
Super+V send_key_state can stick and retrigger the bind (~6k forks/s)
Reported by gw7523 · filed Sep 7, 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
Intel Core Ultra 5 225, NVIDIA GeForce RTX 5080, Omarchy 4.0.2-1, Hyprland 0.56.2 (efb50993780079460b0cbed1363e2166a2de1d9f)
What's wrong?
Stock Super+C / Super+V / Super+X inject send_key_state from the bind callback (default/hypr/bindings/clipboard.lua). The file already cites Hyprland leaving synthetic keys stuck/repeating (hyprwm/Hyprland#14099) and splits down/up by 50ms. That is not enough.
On this machine the Super+V handler retriggered itself in a tight loop:
ns_last_pidclimbed ~6,000/s- the Hyprland session cgroup used ~8.4 cores (about half of that system time)
- host idle was ~2%
- freezing
[email protected]dropped forks to ~40/s; freezing Quickshell or the Hyprland process alone did not - the cgroup was full of short-lived
universal-clipboard/ synthetic-key work - sending explicit key-up for V/C/X and taking injection out of the bind callback dropped idle to ~76% and the Hyprland cgroup to ~1.6 cores in the same session
What happens: Super is still physically down when the bind sends V. Hyprland treats that as another Super+V, fires the bind again, sends V again. repeat = false does not stop this because each synthetic down is a new press.
Expected: one paste chord per Super+V, never a fork bomb.
Workaround that stopped it here: unbind the lua injector and exec a helper that waits for Super to lift, then sends the chord once (with a flock). bindr / { release = true } plus a reentrancy flag in send_shortcut_once would be the in-tree fix — inject only after Super is up, and ignore nested fires while a chord is in flight.
Happy to send a PR against default/hypr/bindings/clipboard.lua.
View raw text
### System details Intel Core Ultra 5 225, NVIDIA GeForce RTX 5080, Omarchy 4.0.2-1, Hyprland 0.56.2 (`efb50993780079460b0cbed1363e2166a2de1d9f`) ### What's wrong? Stock Super+C / Super+V / Super+X inject `send_key_state` from the bind **callback** (`default/hypr/bindings/clipboard.lua`). The file already cites Hyprland leaving synthetic keys stuck/repeating ([hyprwm/Hyprland#14099](https://github.com/hyprwm/Hyprland/discussions/14099)) and splits down/up by 50ms. That is not enough. On this machine the Super+V handler retriggered itself in a tight loop: - `ns_last_pid` climbed ~6,000/s - the Hyprland session cgroup used ~8.4 cores (about half of that **system** time) - host idle was ~2% - freezing `[email protected]` dropped forks to ~40/s; freezing Quickshell or the Hyprland process **alone** did not - the cgroup was full of short-lived `universal-clipboard` / synthetic-key work - sending explicit key-**up** for V/C/X and taking injection **out** of the bind callback dropped idle to ~76% and the Hyprland cgroup to ~1.6 cores in the same session What happens: Super is still physically down when the bind sends `V`. Hyprland treats that as another Super+V, fires the bind again, sends `V` again. `repeat = false` does not stop this because each synthetic down is a new press. Expected: one paste chord per Super+V, never a fork bomb. Workaround that stopped it here: unbind the lua injector and `exec` a helper that waits for Super to lift, then sends the chord once (with a flock). `bindr` / `{ release = true }` plus a reentrancy flag in `send_shortcut_once` would be the in-tree fix — inject only after Super is up, and ignore nested fires while a chord is in flight. Happy to send a PR against `default/hypr/bindings/clipboard.lua`.
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:05 UTC