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-5370GitHub issuePublicDecided· Duplicate

omarchy-menu-keybindings Lua stub makes ipairs infinite (Super+K hang with plugins using hl.get_windows)

Reported by AlxWolfenstein97 · filed Oct 12, 2026 · open at source

Decided: Duplicate — decided by agents · verified 19 h ago.

R-1816 is the earliest report of this defect — filed Aug 15, 2026, open upstream. This report (filed Oct 12, 2026) describes the same defect, so it is folded under it in the inbox.

Decided by agents · verified· Oct 12, 2026

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?
AreaIn the audited areamenu· 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

omarchy-menu-keybindings Lua stub makes ipairs infinite (Super+K hang with plugins using hl.get_windows)revision 1 · captured 2026-10-12 19:39 UTC via poll

Summary

omarchy-menu-keybindings (SUPER + K) builds a Lua bind cache by dofileing ~/.config/hypr/hyprland.lua against a stub hl. That stub’s self-referential noop makes ipairs(hl.get_windows()) never terminate, so any Hyprland toggle/plugin that iterates windows at load time wedges the cheatsheet at ~100% CPU until kill/restart.

Reproduced with duncio/omarchy-cava (backdrop visualizer that recovers its window via ipairs(hl.get_windows()) on load). Same class of bug will hit any future toggle that does the same.

Environment

  • Omarchy 4.0.4-1
  • Hyprland 0.56.2
  • omarchy-menu-keybindings from packaged /usr/share/omarchy/bin/omarchy-menu-keybindings

Steps to reproduce

  1. Install a Hyprland toggle that runs ipairs(hl.get_windows()) at load (e.g. enable io.github.duncio.omarchy-cava, which installs ~/.local/state/omarchy/toggles/hypr/omarchy-cava.lua).
  2. Run omarchy-menu-keybindings --print or press SUPER + K.

Expected

Bind list prints / cheatsheet opens quickly.

Actual

lua child spins at ~100% CPU forever; cheatsheet never appears. Process tree looks like:

omarchy-menu-keybindings → lua (R, ~100% CPU)

Root cause

In build_lua_bind_cache, the stub is effectively:

noop = setmetatable({}, {
  __index = function() return noop end,
  __call = function() return noop end,
})
-- hl.get_windows → noop via __index; noop() → noop via __call

Lua 5.4 ipairs uses __index and stops only on nil. So ipairs(noop) yields forever.

The hang is during require("default.hypr.toggles") after bind lines have already been printed.

The same pattern exists in third-party scanners (e.g. keymap plugin scripts/scan.lua).

Suggested fix (Omarchy)

Make the scanner noop safe for ipairs / #:

noop = setmetatable({}, {
  __index = function(_, key)
    if type(key) == "number" then return nil end
    return noop
  end,
  __call = function() return noop end,
  __len = function() return 0 end,
})

Optionally also set an env like OMARCHY_KEYMAP_SCAN=1 (keymap already honors this) so toggles can skip live bookkeeping intentionally.

Related

Plugin-side report: will link to duncio/omarchy-cava issue after create.

Diagnostic log locally: /tmp/omarchy-debug.log (from omarchy-debug --no-sudo --print).

View raw text
## Summary

`omarchy-menu-keybindings` (`SUPER + K`) builds a Lua bind cache by `dofile`ing `~/.config/hypr/hyprland.lua` against a stub `hl`. That stub’s self-referential noop makes `ipairs(hl.get_windows())` never terminate, so any Hyprland toggle/plugin that iterates windows at load time wedges the cheatsheet at ~100% CPU until kill/restart.

Reproduced with [duncio/omarchy-cava](https://github.com/duncio/omarchy-cava) (backdrop visualizer that recovers its window via `ipairs(hl.get_windows())` on load). Same class of bug will hit any future toggle that does the same.

## Environment

- Omarchy 4.0.4-1
- Hyprland 0.56.2
- `omarchy-menu-keybindings` from packaged `/usr/share/omarchy/bin/omarchy-menu-keybindings`

## Steps to reproduce

1. Install a Hyprland toggle that runs `ipairs(hl.get_windows())` at load (e.g. enable `io.github.duncio.omarchy-cava`, which installs `~/.local/state/omarchy/toggles/hypr/omarchy-cava.lua`).
2. Run `omarchy-menu-keybindings --print` or press `SUPER + K`.

## Expected

Bind list prints / cheatsheet opens quickly.

## Actual

`lua` child spins at ~100% CPU forever; cheatsheet never appears. Process tree looks like:

`omarchy-menu-keybindings` → `lua` (R, ~100% CPU)

## Root cause

In `build_lua_bind_cache`, the stub is effectively:

```lua
noop = setmetatable({}, {
  __index = function() return noop end,
  __call = function() return noop end,
})
-- hl.get_windows → noop via __index; noop() → noop via __call
```

Lua 5.4 `ipairs` uses `__index` and stops only on `nil`. So `ipairs(noop)` yields forever.

The hang is during `require("default.hypr.toggles")` after bind lines have already been printed.

The same pattern exists in third-party scanners (e.g. keymap plugin `scripts/scan.lua`).

## Suggested fix (Omarchy)

Make the scanner noop safe for `ipairs` / `#`:

```lua
noop = setmetatable({}, {
  __index = function(_, key)
    if type(key) == "number" then return nil end
    return noop
  end,
  __call = function() return noop end,
  __len = function() return 0 end,
})
```

Optionally also set an env like `OMARCHY_KEYMAP_SCAN=1` (keymap already honors this) so toggles can skip live bookkeeping intentionally.

## Related

Plugin-side report: will link to `duncio/omarchy-cava` issue after create.

Diagnostic log locally: `/tmp/omarchy-debug.log` (from `omarchy-debug --no-sudo --print`).

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

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.

  • DuplicateR-1816Decided by agents · verified · 2026-10-12 19:48 UTC