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.
SUPER+C/V/X universal clipboard shortcuts fail with "send_key_state: key not found" when a non-Latin keyboard layout is active
Reported by rsoutar · filed Aug 18, 2026 · open at source
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
System details
Intel Core i5-8265U (ThinkPad X390, iGPU), Omarchy omarchy-dev 4.0.0.r1772.gf32ebbd-1, Hyprland 0.56.2, kernel 7.1.8-arch1-3
What's wrong?
With a multi-layout keyboard (e.g. kb_layout = "us,th"), pressing SUPER+C (also SUPER+V / SUPER+X) while the non-Latin layout is active pops up Runtime error in lua: send_key_state: key not found and nothing is copied. It works fine in the English layout.
Steps to reproduce
~/.config/hypr/input.lua:kb_layout = "us,th",kb_options = "grp:caps_toggle"- Switch to Thai (CapsLock), select text in any app, press SUPER+C
- Error popup appears; clipboard unchanged. Switch back to English → works.
Notable: once SUPER+C succeeds once in English after a Hyprland reload, it starts working in Thai too until the next reload (keycode cache).
Root cause (verified against Hyprland v0.56.2 source)
default/hypr/bindings/clipboard.luacallshl.dsp.send_key_state({ mods = "CTRL", key = "C", ... }).- Hyprland's
resolveKeycode(src/config/lua/bindings/LuaBindingsDispatchers.cpp) maps key name"C"→ keysym → keycode by scanning the keymap, but applies the currently active layout group (xkb_state_update_mask(..., KB->m_modifiersState.group)) beforexkb_state_key_get_one_sym(). The Thai group has no Latin keysyms, so"C"is never found and the dispatcher raisessend_key_state: key not foundas a Lua runtime error. - The keycode cache key (keyboard pointer + key name) doesn't include the group — explaining the "works after first success in English" behavior.
- Still present on Hyprland
main(src/keybinds/Resolver.cppusesKB->m_xkbSymState, which tracks the active group).
Possible fixes
- Omarchy: pass evdev keycodes instead of names in
clipboard.lua—key = "code:46"(C),"code:47"(V),"code:45"(X),"code:110"(Insert).resolveKeycodebypasses keysym resolution forcode:NN, so the shortcuts work in any layout — mirroring a physical Ctrl+C press, which toolkits (GTK/Qt) match across layout groups. - Hyprland (upstream):
resolveKeycodeshould search all layout groups (or fall back to group 0) instead of only the active one.
View raw text
### System details
Intel Core i5-8265U (ThinkPad X390, iGPU), Omarchy omarchy-dev 4.0.0.r1772.gf32ebbd-1, Hyprland 0.56.2, kernel 7.1.8-arch1-3
### What's wrong?
With a multi-layout keyboard (e.g. `kb_layout = "us,th"`), pressing SUPER+C (also SUPER+V / SUPER+X) while the non-Latin layout is active pops up `Runtime error in lua: send_key_state: key not found` and nothing is copied. It works fine in the English layout.
## Steps to reproduce
1. `~/.config/hypr/input.lua`: `kb_layout = "us,th"`, `kb_options = "grp:caps_toggle"`
2. Switch to Thai (CapsLock), select text in any app, press SUPER+C
3. Error popup appears; clipboard unchanged. Switch back to English → works.
Notable: once SUPER+C succeeds once in English after a Hyprland reload, it starts working in Thai too until the next reload (keycode cache).
## Root cause (verified against Hyprland v0.56.2 source)
- `default/hypr/bindings/clipboard.lua` calls `hl.dsp.send_key_state({ mods = "CTRL", key = "C", ... })`.
- Hyprland's `resolveKeycode` (`src/config/lua/bindings/LuaBindingsDispatchers.cpp`) maps key name `"C"` → keysym → keycode by scanning the keymap, but applies the **currently active layout group** (`xkb_state_update_mask(..., KB->m_modifiersState.group)`) before `xkb_state_key_get_one_sym()`. The Thai group has no Latin keysyms, so `"C"` is never found and the dispatcher raises `send_key_state: key not found` as a Lua runtime error.
- The keycode cache key (keyboard pointer + key name) doesn't include the group — explaining the "works after first success in English" behavior.
- Still present on Hyprland `main` (`src/keybinds/Resolver.cpp` uses `KB->m_xkbSymState`, which tracks the active group).
## Possible fixes
- Omarchy: pass evdev keycodes instead of names in `clipboard.lua` — `key = "code:46"` (C), `"code:47"` (V), `"code:45"` (X), `"code:110"` (Insert). `resolveKeycode` bypasses keysym resolution for `code:NN`, so the shortcuts work in any layout — mirroring a physical Ctrl+C press, which toolkits (GTK/Qt) match across layout groups.
- Hyprland (upstream): `resolveKeycode` should search all layout groups (or fall back to group 0) instead of only the active one.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 04:42 UTC