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.
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
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?
- 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
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-keybindingsfrom packaged/usr/share/omarchy/bin/omarchy-menu-keybindings
Steps to reproduce
- Install a Hyprland toggle that runs
ipairs(hl.get_windows())at load (e.g. enableio.github.duncio.omarchy-cava, which installs~/.local/state/omarchy/toggles/hypr/omarchy-cava.lua). - Run
omarchy-menu-keybindings --printor pressSUPER + 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 __callLua 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
- Duplicate ofR-1816omarchy-menu-keybindings hangs forever when a user Lua config iterates hl.get_monitors()· decided by agents · verified
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.