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.
Default shift:both_capslock_cancel silently breaks fcitx5 Shift-based hotkeys
Reported by Plutarch01 · filed Sep 30, 2026 · 2 revisionsClosed upstream on 2026-09-30 by its own reporter Plutarch01. GitHub close reason: completed. Closed by its own reporter — not by itself evidence of a fix.
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
Summary
Omarchy's default Hyprland input options and its always-on fcitx5 combine
into a silent failure for anyone using a Shift-based fcitx5 hotkey
(e.g. Alt+Shift layout switching): depending on which key you release
first, the chord does nothing, with zero errors anywhere.
/usr/share/omarchy/default/hypr/input.lua:37 ships:
local kb_options = "compose:caps,shift:both_capslock_cancel"and omarchy-fcitx5.service runs in every graphical session. With that
combination, shift:both_capslock_cancel turns a Shift_L release into aCaps_Lock release, and fcitx5's modifier-only hotkey matching never fires
when Shift is released first. Releasing Alt first always works, so the
failure looks intermittent and even directional.
My case (Omarchy 4.0.4, Hyprland 0.56.2, fcitx5 5.1.22, us,il layouts)
~/.config/fcitx5/confighadAlt+Shift_L/Shift+Alt_Lenumerate keys
with keyboard-us + keyboard-il in the group.
- key_trace=5 proved it: Shift-first releases logged as
Key(Alt+Shift+Caps_Lock ... Release:1 keycode: 50) → noop;
Alt-first releases as Key(Alt+Shift+Alt_L ... Release:1 keycode: 64) →
Input method switched, every time.
- Removing shift:both_capslock_cancel (keeping compose:caps) fixed both
release orders. The cost, stated plainly: with Caps as Compose there is
now no Caps Lock chord left (Both-Shifts was it).
Relation to #4583
Related symptom class (two layout authorities fighting), different
mechanism — that thread is installer-handoff keyboard-us andswap_alt_win. Linking, not duplicating. I am not claiming anything about
XKB grp: toggles, which I did not trace.
Suggestion (pick one)
- Drop
shift:both_capslock_cancelfrom the default (keep
compose:caps), or
2. Keep it, but note in the keyboard manual page that it breaks
Shift-based fcitx5 hotkeys depending on release order, or
3. Have the installer/desktop propagate non-trivial kb_options awareness
to the fcitx5 side.
View raw text
## Summary Omarchy's default Hyprland input options and its always-on fcitx5 combine into a silent failure for anyone using a `Shift`-based fcitx5 hotkey (e.g. `Alt+Shift` layout switching): depending on which key you release first, the chord does nothing, with zero errors anywhere. ` /usr/share/omarchy/default/hypr/input.lua:37` ships: ```lua local kb_options = "compose:caps,shift:both_capslock_cancel" ``` and `omarchy-fcitx5.service` runs in every graphical session. With that combination, `shift:both_capslock_cancel` turns a `Shift_L` release into a `Caps_Lock` release, and fcitx5's modifier-only hotkey matching never fires when Shift is released first. Releasing `Alt` first always works, so the failure looks intermittent and even directional. ## My case (Omarchy 4.0.4, Hyprland 0.56.2, fcitx5 5.1.22, `us,il` layouts) - `~/.config/fcitx5/config` had `Alt+Shift_L` / `Shift+Alt_L` enumerate keys with `keyboard-us` + `keyboard-il` in the group. - `key_trace=5` proved it: Shift-first releases logged as `Key(Alt+Shift+Caps_Lock ... Release:1 keycode: 50)` → noop; Alt-first releases as `Key(Alt+Shift+Alt_L ... Release:1 keycode: 64)` → `Input method switched`, every time. - Removing `shift:both_capslock_cancel` (keeping `compose:caps`) fixed both release orders. The cost, stated plainly: with Caps as Compose there is now no Caps Lock chord left (Both-Shifts was it). ## Relation to #4583 Related symptom class (two layout authorities fighting), different mechanism — that thread is installer-handoff `keyboard-us` and `swap_alt_win`. Linking, not duplicating. I am not claiming anything about XKB `grp:` toggles, which I did not trace. ## Suggestion (pick one) 1. Drop `shift:both_capslock_cancel` from the default (keep `compose:caps`), or 2. Keep it, but note in the keyboard manual page that it breaks `Shift`-based fcitx5 hotkeys depending on release order, or 3. Have the installer/desktop propagate non-trivial `kb_options` awareness to the fcitx5 side.
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.
No decision has been recorded yet.