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 hangs indefinitely when cache needs regeneration
Reported by zonk911 · filed Sep 8, 2026Closed upstream on 2026-09-08 by its own reporter zonk911, as a duplicate of #10737 (R-4952). GitHub close reason: duplicate.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Description
After an omarchy update that changes keybindings or the keymap, omarchy-menu-keybindings (triggered by SUPER + K or the keybindings menu entry) hangs indefinitely. The command produces no output and must be killed with a timeout.
The root cause is in build_lua_bind_cache() in /usr/bin/omarchy-menu-keybindings. The Lua process spawned via process substitution (< <(lua << LUA ... >>)) does not terminate when run from within the full script context, causing the while read loop to hang forever.
Steps to Reproduce
- Have a system where the keybinding cache key changes (e.g., after an update that adds/modifies bindings or changes the keymap)
- Delete the current cache:
rm ~/.cache/omarchy/keybindings-*.records - Run
omarchy-menu-keybindings --print - The command hangs indefinitely (observed: 60+ seconds without completing)
Expected Behavior
The command should complete within a few seconds and display the keybindings menu.
Workaround
Manually copy an existing cache file with the new cache key:
# Find the expected cache key
new_key=$(printf "v11\n" && hyprctl devices 2>/dev/null | grep -F "active keymap:" && hyprctl binds 2>/dev/null) | sha256sum | awk "{ print \$1 }"
# Find and copy the most recent existing cache
ls -t ~/.cache/omarchy/keybindings-*.records | head -1 | xargs cp ~/.cache/omarchy/keybindings-"$new_key".recordsEnvironment
- Omarchy: 4.0.3rc3-1
- Hyprland: 0.56.2
- Bash: 5.3.15(1)-release
- Lua: 5.5.1
- Cache accumulates many empty temp files (
keybindings.XXXXXXwith 0 bytes) in~/.cache/omarchy/due to repeated failed regeneration attempts
Additional Notes
- The Lua script itself completes in ~10 seconds when run directly (
lua <script>), but hangs indefinitely when run from within the bash script via process substitution - The issue is specifically in the
build_lua_bind_cache()function and its interaction withdofile()on the Hyprland Lua config - After the cache is manually created/fixed,
SUPER + Kworks immediately - 59 empty temp files were found in
~/.cache/omarchy/from repeated failed attempts
View raw text
## Description
After an `omarchy update` that changes keybindings or the keymap, `omarchy-menu-keybindings` (triggered by `SUPER + K` or the keybindings menu entry) hangs indefinitely. The command produces no output and must be killed with a timeout.
The root cause is in `build_lua_bind_cache()` in `/usr/bin/omarchy-menu-keybindings`. The Lua process spawned via process substitution (`< <(lua << LUA ... >>)`) does not terminate when run from within the full script context, causing the `while read` loop to hang forever.
## Steps to Reproduce
1. Have a system where the keybinding cache key changes (e.g., after an update that adds/modifies bindings or changes the keymap)
2. Delete the current cache: `rm ~/.cache/omarchy/keybindings-*.records`
3. Run `omarchy-menu-keybindings --print`
4. The command hangs indefinitely (observed: 60+ seconds without completing)
## Expected Behavior
The command should complete within a few seconds and display the keybindings menu.
## Workaround
Manually copy an existing cache file with the new cache key:
```bash
# Find the expected cache key
new_key=$(printf "v11\n" && hyprctl devices 2>/dev/null | grep -F "active keymap:" && hyprctl binds 2>/dev/null) | sha256sum | awk "{ print \$1 }"
# Find and copy the most recent existing cache
ls -t ~/.cache/omarchy/keybindings-*.records | head -1 | xargs cp ~/.cache/omarchy/keybindings-"$new_key".records
```
## Environment
- Omarchy: 4.0.3rc3-1
- Hyprland: 0.56.2
- Bash: 5.3.15(1)-release
- Lua: 5.5.1
- Cache accumulates many empty temp files (`keybindings.XXXXXX` with 0 bytes) in `~/.cache/omarchy/` due to repeated failed regeneration attempts
## Additional Notes
- The Lua script itself completes in ~10 seconds when run directly (`lua <script>`), but hangs indefinitely when run from within the bash script via process substitution
- The issue is specifically in the `build_lua_bind_cache()` function and its interaction with `dofile()` on the Hyprland Lua config
- After the cache is manually created/fixed, `SUPER + K` works immediately
- 59 empty temp files were found in `~/.cache/omarchy/` from repeated failed attempts
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
- Fixed bypr/12712· confirmed
- Fixed bypr/11733· confirmed
- Fixed bypr/7564· confirmed
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.
No decision has been recorded yet.