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.
Default Enter keybindings never match on keyboards that emit KP_Enter
Reported by chrishthompson · filed Aug 29, 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 happened
On a Gateway GWTN141-10 laptop, none of the default Enter keybindings work: SUPER+Enter (Terminal), SUPER+SHIFT+Enter (Browser), SUPER+ALT+Enter (Tmux), SUPER+CTRL+Enter (Herdr) all do nothing. Every other keybinding works normally.
Root cause (verified)
This laptop's built-in keyboard emits KP_Enter (evdev KEY_KPENTER 96, xkb keycode 104, keysym 0xff8d) for its main Enter key instead of Return. Applications treat KP_Enter and Return identically, so typing is unaffected and the quirk is invisible in normal use — but Omarchy's bindings in default/hypr/bindings/applications.lua are declared only for RETURN, so they never match.
Verified by hooking CKeybindManager::handleKeybinds in Hyprland and logging physical presses:
press: mods=64 keysym=0xff8d (KP_Enter) keycode=104 dev=[at-translated-set-2-keyboard]
press: mods=65 keysym=0xff8d (KP_Enter) keycode=104 dev=[at-translated-set-2-keyboard]Adding a SUPER + KP_Enter binding makes the same physical key work immediately.
Steps to reproduce (any hardware)
You don't need this laptop: on any full-size keyboard, press SUPER + numpad-Enter. Nothing opens, while SUPER + main-Enter opens the terminal. Affected laptops just have no Enter key that emits Return at all.
Expected
The Enter bindings should respond to both Enter keys, as applications do.
Proposed fix
Mirror the RETURN bindings onto KP_Enter in default/hypr/bindings/applications.lua:
o.bind("SUPER + KP_Enter", "Terminal", { omarchy = "terminal" })
o.bind("SUPER + SHIFT + KP_Enter", "Browser", { omarchy = "browser" })
-- and the Tmux/Herdr variants under the same guards as the RETURN versionsThe RETURN bind in the slurp selection overlay (default/hypr/bindings/utilities.lua, "Capture highlighted window") has the same gap.
If duplicate entries in the keybindings menu are a concern, the KP_Enter mirrors could be registered without descriptions.
Workaround
-- ~/.config/hypr/bindings.lua
o.bind("SUPER + KP_Enter", "Terminal", { omarchy = "terminal" })
o.bind("SUPER + SHIFT + KP_Enter", "Browser", { omarchy = "browser" })
o.bind("SUPER + ALT + KP_Enter", "Tmux", { omarchy = "terminal-tmux" })
o.bind("SUPER + CTRL + KP_Enter", "Herdr", { omarchy = "terminal-herdr" })System details
- Omarchy 4.0.1-1, Hyprland 0.56.2
- Gateway GWTN141-10 (sys_vendor "GPU Company"), Intel i5-1135G7, Iris Xe
- Keyboard: built-in (
at-translated-set-2-keyboard), layoutus
View raw text
## What happened
On a Gateway GWTN141-10 laptop, none of the default Enter keybindings work: SUPER+Enter (Terminal), SUPER+SHIFT+Enter (Browser), SUPER+ALT+Enter (Tmux), SUPER+CTRL+Enter (Herdr) all do nothing. Every other keybinding works normally.
## Root cause (verified)
This laptop's built-in keyboard emits **KP_Enter** (evdev `KEY_KPENTER` 96, xkb keycode 104, keysym `0xff8d`) for its main Enter key instead of `Return`. Applications treat KP_Enter and Return identically, so typing is unaffected and the quirk is invisible in normal use — but Omarchy's bindings in `default/hypr/bindings/applications.lua` are declared only for `RETURN`, so they never match.
Verified by hooking `CKeybindManager::handleKeybinds` in Hyprland and logging physical presses:
```
press: mods=64 keysym=0xff8d (KP_Enter) keycode=104 dev=[at-translated-set-2-keyboard]
press: mods=65 keysym=0xff8d (KP_Enter) keycode=104 dev=[at-translated-set-2-keyboard]
```
Adding a `SUPER + KP_Enter` binding makes the same physical key work immediately.
## Steps to reproduce (any hardware)
You don't need this laptop: on any full-size keyboard, press **SUPER + numpad-Enter**. Nothing opens, while SUPER + main-Enter opens the terminal. Affected laptops just have no Enter key that emits `Return` at all.
## Expected
The Enter bindings should respond to both Enter keys, as applications do.
## Proposed fix
Mirror the `RETURN` bindings onto `KP_Enter` in `default/hypr/bindings/applications.lua`:
```lua
o.bind("SUPER + KP_Enter", "Terminal", { omarchy = "terminal" })
o.bind("SUPER + SHIFT + KP_Enter", "Browser", { omarchy = "browser" })
-- and the Tmux/Herdr variants under the same guards as the RETURN versions
```
The `RETURN` bind in the slurp selection overlay (`default/hypr/bindings/utilities.lua`, "Capture highlighted window") has the same gap.
If duplicate entries in the keybindings menu are a concern, the KP_Enter mirrors could be registered without descriptions.
## Workaround
```lua
-- ~/.config/hypr/bindings.lua
o.bind("SUPER + KP_Enter", "Terminal", { omarchy = "terminal" })
o.bind("SUPER + SHIFT + KP_Enter", "Browser", { omarchy = "browser" })
o.bind("SUPER + ALT + KP_Enter", "Tmux", { omarchy = "terminal-tmux" })
o.bind("SUPER + CTRL + KP_Enter", "Herdr", { omarchy = "terminal-herdr" })
```
## System details
- Omarchy 4.0.1-1, Hyprland 0.56.2
- Gateway GWTN141-10 (sys_vendor "GPU Company"), Intel i5-1135G7, Iris Xe
- Keyboard: built-in (`at-translated-set-2-keyboard`), layout `us`
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:03 UTC