Repository navigation
omarchy-menu-keybindings: mock 'noop' table causes unbounded infinite loop and 100% CPU when config iterates with ipairs #12124
Description
System details
Intel Core i7-8665U, Intel UHD Graphics 620, Omarchy 4.0.4-1
What's wrong?
Description
When pressing SUPER + K (or running omarchy menu keybindings / omarchy-menu-keybindings), if the user's Hyprland Lua configuration (or any module it requires) uses ipairs() on a function call or table that falls back to the mock noop object (for example, ipairs(hl.get_windows() or {})), the subshell Lua process enters an infinite loop, never exits, and spins at 100% CPU.
Each time SUPER + K is pressed, another un-reaped lua process is spawned and pegs a CPU core permanently.
Steps to Reproduce
- In
~/.config/hypr/hyprland.lua(or a required module), add any standard Lua loop that iterates over a mockable Hyprland API, such as:(Note: This is completely valid Lua inside the real Hyprland compositor).for _, w in ipairs(hl.get_windows() or {}) do -- window handling logic end
- Clear the keybindings cache:
rm -f ~/.cache/omarchy/keybindings-*.records
- Press
SUPER + Kor execute:omarchy-menu-keybindings --print
- Observe that the command never completes, and
ps aux | grep luashows aluaprocess consuming 100% CPU.
Root Cause
In /usr/share/omarchy/bin/omarchy-menu-keybindings:
local noop
noop = setmetatable({}, {
__index = function()
return noop
end,
__call = function()
return noop
end,
})
hl = setmetatable({
dsp = dsp_proxy("hl.dsp"),
bind = function(keys, bind_dispatcher, opts)
-- ...
end,
get_config = function()
return nil
end,
}, {
__index = function()
return noop
end,
})omarchy-menu-keybindings parses user keybindings by executing dofile("~/.config/hypr/hyprland.lua") in a standalone lua subshell.
To avoid crashes on unhandled Hyprland APIs, it falls back to a recursive noop mock.
However, in Lua, ipairs(t) iterates sequentially (t[1], t[2], t[3], ...) until the table returns nil. Because noop's __index returns noop (which is truthy) for all keys, noop[1], noop[2], etc. are never nil. As a result, ipairs(noop) becomes an infinite loop.
Proposed Solution
In /usr/share/omarchy/bin/omarchy-menu-keybindings, update noop so that numeric index lookups return nil:
local noop
noop = setmetatable({}, {
__index = function(self, key)
if type(key) == "number" then
return nil
end
return noop
end,
__call = function()
return noop
end,
__len = function()
return 0
end,
})Additionally, common query functions like hl.get_windows, hl.get_monitors, hl.get_workspaces can be explicitly stubbed on hl to return {}:
get_windows = function() return {} end,
get_monitors = function() return {} end,
get_workspaces = function() return {} end,
Activity
omarchybot commentedon Oct 12, 2026
Confirmed from source on current
quattro(9480d1b):build_lua_bind_cache()inbin/omarchy-menu-keybindingsstill runshyprland.luaunder a stubhlwhosenoopfallback answers every key with itself (lines 209–217).hl.get_windows()returnsnoop, which is truthy, soor {}never applies, andipairsnever reaches anil.pcallcatches errors but not a loop that never ends, and nothing time-boxes the scan, so theluaprocess spins until killed. The same report is open as #7025, which is where the earlier duplicates were closed into.The fix is already an open pull request: #7564 makes
noopanswernilfor numeric keys, which is the change proposed here, and wraps the scan intimeout 10. It already lists this issue as one it closes. It no longer applies cleanly toquattro, though. It was written against an older copy of the script, so bringing it up to date has to keep the scan's currentlua -E -invocation and its cache key bump has to move pastv15. Its test's extractor also matches the old invocation only. #11733 and #14128 take other approaches to the same hang.Checked by Claude Opus 5.5 and Codex Medium as a second opinion, each reading the script and #7564's diff. Codex agreed on the mechanism and the fix, and found the conflicts with current
quattrodescribed above. Nothing was run for this issue: the cause is plain from the source, and #7564 will be tested as its own item. The bug is fixed when #7564, or one of the alternatives, lands, so this waits on the maintainer.jandrusk commentedon Oct 13, 2026
Still present on
quattro: thenoopstub answers numeric keys with itself, soipairs(hl.get_windows())never terminates. Same root cause as #15216, #14302, #14243, #7025.Canonical tracker — please dup the others here (or to whichever fix PR lands). A fix hunk also lives inside the #12155 bundle; prefer a single-purpose PR.
omarchybot commentedon Oct 14, 2026
Re-checked since my last comment. The bug is unchanged, and so is the fix side: #7564 still lists this issue among the ones it closes, and #12712, #14128 and #11733 are still open as other approaches to the same hang. Choosing between them is the maintainer's call.
This report and #7025 describe the same stub
nooploop inbin/omarchy-menu-keybindings, and #14243, #14302 and #15216 look like the same again. I asked whether to close this one into #7025, the older report. Claude Opus 5.5 read both as the same bug, but Codex Medium, asked separately from the two reports alone, did not agree, so this stays open. Which report becomes the tracker is left to the maintainer, and whichever fix lands closes it, since #7564 already links both.Nothing was run for this re-check. This waits on the maintainer.