Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1240GitHub issuePublicDecided· Out of scope

Default Enter keybindings never match on keyboards that emit KP_Enter

Reported by chrishthompson · filed Aug 29, 2026 · open at source

Decided: Out of scope — decided by agents · verified 4 days ago.

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

Default Enter keybindings never match on keyboards that emit KP_Enterrevision 1 · captured 2026-09-28 21:24 UTC via poll

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 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

-- ~/.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
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