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.
Cloning omarchy.menu leaves the Apps submenu empty; the clone's Menu.qml never renders
Reported by maxdmayhew · filed Sep 11, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #10661 (R-860). GitHub close reason: completed.
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
What happened
Cloning the first-party menu plugin with omarchy plugin clone omarchy.menu silently breaks the Apps submenu: it renders "Nothing here yet" and lists no applications. Every static menu route (Learn, Style, Setup, System, …) keeps working, so the menu looks healthy apart from app launching.
The clone also never actually renders. Edits to the clone's own Menu.qml have no effect on screen, even though the shell logs that it reloaded the plugin.
Expected
A cloned menu plugin should render its own Menu.qml and keep a working Apps submenu.
Steps to reproduce
- On a stock install, run
omarchy plugin clone omarchy.menu(produces~/.config/omarchy/plugins/<user>.menu/).
This writes to ~/.config/omarchy/shell.json:
"disabledPlugins": ["omarchy.menu"],
"cloneSourceRestores": ["<user>.menu"] and points the bar's menu widget at the clone.
2. Open the menu (SUPER+SPACE) and go to Apps.
3. The list is empty — "Nothing here yet". Persists across omarchy restart shell and a full omarchy update.
Diagnosis
The desktop-entry pipeline is healthy — the fault is isolated to the plugin capability wiring.
DesktopEntries.applicationsresolves 62 entries; 45 survivedefault/omarchy/launcher.hides(39 ids) plusshell/services/hidden-entries.sh(29 ids).- Instantiating
shell/services/AppLibrary.qmlstandalone under a scratch Quickshell config returns exactly those 45 rows fromsortedEntries(""), soAppLibrary, the hide-lists andAppSearch.jsare all fine. MenuModel.parseMenuJsonc+mergeMenuSourceson the shipped JSONC (checked under node) yields 334 items, and theappsrow keeps"provider":"apps", so the menu model is fine.pacman -Qkk omarchyreports 0 altered files.
The clone's menu entry point is never used. Replacing the empty-state string in the clone's Menu.qml ("Nothing here yet" → a marker) changed nothing on screen, while the shell logged Local plugin changed, reloading: <user>.menu. The menu being drawn is the packaged omarchy.menu code — the plugin that step 1 just added to disabledPlugins.
Likely mechanism (inferred from source, not instrumented): appLibrary is injected in shell.qml → createScopedPluginShell() and reaches the menu via Menu.qml's readonly property var appLibrary: root.shell ? root.shell.appLibrary : null. mergeAppRows() begins with if (!root.appLibrary) return, so a menu surface rendered from a plugin that is listed in disabledPlugins contributes no app rows and silently shows the empty state.
Workaround
Remove omarchy.menu from disabledPlugins in ~/.config/omarchy/shell.json (and drop cloneSourceRestores). The Apps list returns immediately.
To keep a custom bar icon without cloning the whole menu, a "kinds": ["bar-widget"]-only user plugin whose BarWidget.qml runs omarchy-shell shell toggle omarchy.menu '{"menu":"root"}' works and leaves omarchy.menu enabled.
System
| Omarchy | 4.0.3-1 |
| Kernel | 7.2.3-arch1-3 |
| Hyprland | 0.56.2-2 |
| Quickshell | 0.3.1-1 |
| qt6-base | 6.11.2-3 |
| CPU | 11th Gen Intel Core i7-1185G7 |
| GPU | Intel TigerLake-LP GT2 [Iris Xe Graphics] |
Note: omarchy debug --no-sudo --print referenced in the docs is not a valid command on 4.0.3 (Unknown Omarchy command), so the details above were collected manually.
View raw text
## What happened
Cloning the first-party menu plugin with `omarchy plugin clone omarchy.menu` silently breaks the **Apps** submenu: it renders "Nothing here yet" and lists no applications. Every static menu route (Learn, Style, Setup, System, …) keeps working, so the menu looks healthy apart from app launching.
The clone also never actually renders. Edits to the clone's own `Menu.qml` have no effect on screen, even though the shell logs that it reloaded the plugin.
## Expected
A cloned menu plugin should render its own `Menu.qml` and keep a working Apps submenu.
## Steps to reproduce
1. On a stock install, run `omarchy plugin clone omarchy.menu` (produces `~/.config/omarchy/plugins/<user>.menu/`).
This writes to `~/.config/omarchy/shell.json`:
```json
"disabledPlugins": ["omarchy.menu"],
"cloneSourceRestores": ["<user>.menu"]
```
and points the bar's menu widget at the clone.
2. Open the menu (SUPER+SPACE) and go to **Apps**.
3. The list is empty — "Nothing here yet". Persists across `omarchy restart shell` and a full `omarchy update`.
## Diagnosis
The desktop-entry pipeline is healthy — the fault is isolated to the plugin capability wiring.
- `DesktopEntries.applications` resolves **62** entries; **45** survive `default/omarchy/launcher.hides` (39 ids) plus `shell/services/hidden-entries.sh` (29 ids).
- Instantiating `shell/services/AppLibrary.qml` standalone under a scratch Quickshell config returns exactly those **45** rows from `sortedEntries("")`, so `AppLibrary`, the hide-lists and `AppSearch.js` are all fine.
- `MenuModel.parseMenuJsonc` + `mergeMenuSources` on the shipped JSONC (checked under node) yields 334 items, and the `apps` row keeps `"provider":"apps"`, so the menu model is fine.
- `pacman -Qkk omarchy` reports 0 altered files.
**The clone's menu entry point is never used.** Replacing the empty-state string in the clone's `Menu.qml` (`"Nothing here yet"` → a marker) changed nothing on screen, while the shell logged `Local plugin changed, reloading: <user>.menu`. The menu being drawn is the packaged `omarchy.menu` code — the plugin that step 1 just added to `disabledPlugins`.
Likely mechanism (inferred from source, not instrumented): `appLibrary` is injected in `shell.qml` → `createScopedPluginShell()` and reaches the menu via `Menu.qml`'s `readonly property var appLibrary: root.shell ? root.shell.appLibrary : null`. `mergeAppRows()` begins with `if (!root.appLibrary) return`, so a menu surface rendered from a plugin that is listed in `disabledPlugins` contributes no app rows and silently shows the empty state.
## Workaround
Remove `omarchy.menu` from `disabledPlugins` in `~/.config/omarchy/shell.json` (and drop `cloneSourceRestores`). The Apps list returns immediately.
To keep a custom bar icon without cloning the whole menu, a `"kinds": ["bar-widget"]`-only user plugin whose `BarWidget.qml` runs `omarchy-shell shell toggle omarchy.menu '{"menu":"root"}'` works and leaves `omarchy.menu` enabled.
## System
| | |
|---|---|
| Omarchy | 4.0.3-1 |
| Kernel | 7.2.3-arch1-3 |
| Hyprland | 0.56.2-2 |
| Quickshell | 0.3.1-1 |
| qt6-base | 6.11.2-3 |
| CPU | 11th Gen Intel Core i7-1185G7 |
| GPU | Intel TigerLake-LP GT2 [Iris Xe Graphics] |
Note: `omarchy debug --no-sudo --print` referenced in the docs is not a valid command on 4.0.3 (`Unknown Omarchy command`), so the details above were collected manually.
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.