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.
Theme switcher and background keybindings broken: menu never renders, theme set silently fails from menu action
Reported by simfliXD · filed Aug 25, 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?
- 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. So far: in the audited area (menu) — decided by agents · verified; matches no known issue — decided by arbitration. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
System details
- AMD Radeon RX 6650 XT (Navi 23)
- Hyprland 0.56.2
- Omarchy
devbranch - Kernel: Linux 7.1.9-zen1-2-zen
What is wrong?
Two related issues:
1. Keybindings for theme/background switcher do nothing
SUPER+SHIFT+CTRL+SPACE (theme switcher) and SUPER+CTRL+SPACE (background switcher) are registered in Hyprland (hyprctl binds) and the IPC call succeeds (omarchy-menu toggle theme returns ok), but no menu layer surface appears. hyprctl layers shows no omarchy-menu namespace at all.
- The Quickshell shell is running and responsive to
ping - The menu plugin (
omarchy.menu) responds tocall omarchy.menu pingwithok - The shell
toggle/summonIPC returnsok - But no
WlrLayershellsurface is ever created for the menu
Double-clicking the desktop background does work — it calls omarchy-theme-bg-switcher / omarchy-theme-switcher directly via QML Process, bypassing the shell menu entirely.
2. Theme picker works but does not apply theme from menu action
When running omarchy theme switcher from a terminal, the image picker shows, a theme is selected, and the name is echoed — but the theme is not applied. Running the same chain manually works:
theme=$(omarchy-theme-switcher)
omarchy-theme-set "$theme"This works from a terminal but the menu action (which uses Util.execDetached → bash -lc) apparently does not execute omarchy-theme-set successfully.
Steps to reproduce
- Press
SUPER+SHIFT+CTRL+SPACE→ nothing happens - Press
SUPER+CTRL+SPACE→ nothing happens - Double-click desktop background → picker opens and works
- Run
omarchy theme switcherfrom terminal → picker opens, theme name echoed, but theme not changed - Run
omarchy theme set "Catppuccin"from terminal → theme changes successfully
Diagnostic observations
- Stale quickshell instance directories accumulate in
/run/user/1000/quickshell/by-id/(multiple dead PIDs) - Killing the quickshell process and restarting via
omarchy restart shellresolved stale state but did not fix the menu rendering hyprctl layersonly ever showsomarchy-backgroundandomarchy-bar— neveromarchy-menu- The shell log shows menu-related image warnings but no errors indicating the menu Loader or PanelWindow failed to instantiate
keepLoaded: trueis set in the menu manifest, yet the panel window never materializes a layer surface
View raw text
## System details - AMD Radeon RX 6650 XT (Navi 23) - Hyprland 0.56.2 - Omarchy `dev` branch - Kernel: Linux 7.1.9-zen1-2-zen ## What is wrong? Two related issues: ### 1. Keybindings for theme/background switcher do nothing `SUPER+SHIFT+CTRL+SPACE` (theme switcher) and `SUPER+CTRL+SPACE` (background switcher) are registered in Hyprland (`hyprctl binds`) and the IPC call succeeds (`omarchy-menu toggle theme` returns `ok`), but **no menu layer surface appears**. `hyprctl layers` shows no `omarchy-menu` namespace at all. - The Quickshell shell is running and responsive to `ping` - The menu plugin (`omarchy.menu`) responds to `call omarchy.menu ping` with `ok` - The shell `toggle`/`summon` IPC returns `ok` - But no `WlrLayershell` surface is ever created for the menu Double-clicking the desktop background **does** work — it calls `omarchy-theme-bg-switcher` / `omarchy-theme-switcher` directly via QML Process, bypassing the shell menu entirely. ### 2. Theme picker works but does not apply theme from menu action When running `omarchy theme switcher` from a terminal, the image picker shows, a theme is selected, and the name is echoed — but the theme is **not applied**. Running the same chain manually works: ```bash theme=$(omarchy-theme-switcher) omarchy-theme-set "$theme" ``` This works from a terminal but the menu action (which uses `Util.execDetached` → `bash -lc`) apparently does not execute `omarchy-theme-set` successfully. ## Steps to reproduce 1. Press `SUPER+SHIFT+CTRL+SPACE` → nothing happens 2. Press `SUPER+CTRL+SPACE` → nothing happens 3. Double-click desktop background → picker opens and works 4. Run `omarchy theme switcher` from terminal → picker opens, theme name echoed, but theme not changed 5. Run `omarchy theme set "Catppuccin"` from terminal → theme changes successfully ## Diagnostic observations - Stale quickshell instance directories accumulate in `/run/user/1000/quickshell/by-id/` (multiple dead PIDs) - Killing the quickshell process and restarting via `omarchy restart shell` resolved stale state but did not fix the menu rendering - `hyprctl layers` only ever shows `omarchy-background` and `omarchy-bar` — never `omarchy-menu` - The shell log shows menu-related image warnings but no errors indicating the menu Loader or PanelWindow failed to instantiate - `keepLoaded: true` is set in the menu manifest, yet the panel window never materializes a layer surface
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.
- Decided by agents · verified: in the audited area (menu)
- Decided by arbitration: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.