Proof Portal

Sign in
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-247GitHub issuePublicDecided· Out of scope

Workspace keybindings (SUPER+1..0) don't switch workspaces on Hyprland 0.56: code: keycodes and hl.dsp.focus binding form fail silently

Reported by dsundt · filed Sep 21, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 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

Workspace keybindings (SUPER+1..0) don't switch workspaces on Hyprland 0.56: code: keycodes and hl.dsp.focus binding form fail silentlyrevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

On a fresh Omarchy install (default bindings untouched), the workspace keybindings do not work:

  • SUPER + 1..0 does not switch workspaces
  • SUPER + SHIFT + 1..0 does not move the focused window
  • SUPER + SHIFT + ALT + 1..0 does not move silently

Pressing the keys produces no effect and no error. Other default bindings (e.g. SUPER + J, SUPER + W) fire normally.

Root causes found (three compounding issues)

  1. `code:N` key form does not match presses. The defaults in default/hypr/bindings/tiling.lua bind SUPER + code:10..code:19. On this machine those never fire. Captured raw events at /dev/input/eventX while pressing SUPER+1: KEY_LEFTMETA (125) then KEY_1 (2) are delivered correctly, but the binding is not triggered. Re-binding the same actions to the keysym form (SUPER + 1) fires. (Note: this machine uses a Keychron K10 HE over Bluetooth; the capture shows standard evdev codes, so the mismatch appears to be in Hyprland's code: resolution, not the keyboard.)
  1. `hl.dsp.focus({ workspace = \"N\" })` fails silently as a binding dispatcher. The default uses hl.dsp.focus({ workspace = tostring(workspace) }). At binding time this registers but never switches. hl.dsp.focus reports its accepted arguments as only direction, monitor, window, urgent_or_last, last — no workspace key. A bare \"1\" value is silently ignored. \"id:1\" works intermittently via hyprctl eval but stopped working entirely after a few config reloads.
  1. The only form verified to work end-to-end is a shell dispatch with the bare workspace number:

hyprctl dispatch \"hl.dsp.focus({ workspace = \\\"N\\\" })\" (and the analogous hl.dsp.window.move({ workspace = \\\"N\\\" })). The bundled omarchy shell bar widget (shell/plugins/bar/widgets/Workspaces.qml) uses exactly this dispatch form, which is why bar clicks switch workspaces while the keyboard bindings do not.

Related

  • SUPER + J (Toggle window split, hl.dsp.layout(\"togglesplit\")) errors with no such layoutmsg for scrolling on workspaces in the scrolling layout (Omarchy's default layout for new workspaces on this version). togglesplit is dwindle-only; the binding is registered unconditionally.

Workaround applied locally

~/.config/hypr/bindings.lua re-binds all 30 workspace bindings to keysym keys dispatching through the hyprctl dispatch form above.

System details

  • Omarchy 4.0.0.r2158.gd174d4a-1
  • Hyprland 0.56.2 (commit efb50993780079460b0cbed1363e2166a2de1d9f)
  • Kernel 7.2.5-4-omarchy
  • Lenovo ThinkPad P16s Gen 4 AMD (DMI 21QSS16N00), AMD Krackan, Radeon 860M
  • Peripherals: Keychron K10 HE (Bluetooth, channel 2), Logitech LIFT (Bolt receiver)

Expected behavior

SUPER + 1 switches to workspace 1; SUPER + SHIFT + 1 moves the focused window there.

View raw text
## What happened

On a fresh Omarchy install (default bindings untouched), the workspace keybindings do not work:

- `SUPER + 1..0` does not switch workspaces
- `SUPER + SHIFT + 1..0` does not move the focused window
- `SUPER + SHIFT + ALT + 1..0` does not move silently

Pressing the keys produces no effect and no error. Other default bindings (e.g. `SUPER + J`, `SUPER + W`) fire normally.

## Root causes found (three compounding issues)

1. **`code:N` key form does not match presses.** The defaults in `default/hypr/bindings/tiling.lua` bind `SUPER + code:10`..`code:19`. On this machine those never fire. Captured raw events at `/dev/input/eventX` while pressing SUPER+1: `KEY_LEFTMETA` (125) then `KEY_1` (2) are delivered correctly, but the binding is not triggered. Re-binding the same actions to the keysym form (`SUPER + 1`) fires. (Note: this machine uses a Keychron K10 HE over Bluetooth; the capture shows standard evdev codes, so the mismatch appears to be in Hyprland's `code:` resolution, not the keyboard.)

2. **`hl.dsp.focus({ workspace = \"N\" })` fails silently as a binding dispatcher.** The default uses `hl.dsp.focus({ workspace = tostring(workspace) })`. At binding time this registers but never switches. `hl.dsp.focus` reports its accepted arguments as only `direction, monitor, window, urgent_or_last, last` — no `workspace` key. A bare `\"1\"` value is silently ignored. `\"id:1\"` works intermittently via `hyprctl eval` but stopped working entirely after a few config reloads.

3. **The only form verified to work end-to-end** is a shell dispatch with the bare workspace number:
   `hyprctl dispatch \"hl.dsp.focus({ workspace = \\\"N\\\" })\"` (and the analogous `hl.dsp.window.move({ workspace = \\\"N\\\" })`). The bundled omarchy shell bar widget (`shell/plugins/bar/widgets/Workspaces.qml`) uses exactly this dispatch form, which is why bar clicks switch workspaces while the keyboard bindings do not.

## Related

- `SUPER + J` (Toggle window split, `hl.dsp.layout(\"togglesplit\")`) errors with `no such layoutmsg for scrolling` on workspaces in the scrolling layout (Omarchy's default layout for new workspaces on this version). togglesplit is dwindle-only; the binding is registered unconditionally.

## Workaround applied locally

`~/.config/hypr/bindings.lua` re-binds all 30 workspace bindings to keysym keys dispatching through the `hyprctl dispatch` form above.

## System details

- Omarchy `4.0.0.r2158.gd174d4a-1`
- Hyprland `0.56.2` (commit efb50993780079460b0cbed1363e2166a2de1d9f)
- Kernel `7.2.5-4-omarchy`
- Lenovo ThinkPad P16s Gen 4 AMD (DMI 21QSS16N00), AMD Krackan, Radeon 860M
- Peripherals: Keychron K10 HE (Bluetooth, channel 2), Logitech LIFT (Bolt receiver)

## Expected behavior

`SUPER + 1` switches to workspace 1; `SUPER + SHIFT + 1` moves the focused window there.

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 16:56 UTC