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.
Cloned omarchy.menu plugin shows empty Apps submenu
Reported by AndreyCJ · filed Sep 9, 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
Omarchy version: 4.0.3-1 (Arch Linux, Hyprland, Quickshell shell)
Summary
Cloning the first-party omarchy.menu plugin with omarchy plugin clone omarchy.menu
(which creates ~/.config/omarchy/plugins/<user>.menu/) produces a menu whose
Apps submenu is empty — no application rows are ever populated. The built-in
first-party omarchy.menu shows all applications correctly. Re-cloning a fresh,
byte-identical copy does not fix it.
Expected
The cloned menu should populate the Apps submenu with the same desktop entries as
the built-in omarchy.menu.
Actual
The Apps submenu renders with zero rows. No error is printed to the Quickshell
log (/run/user/<uid>/quickshell/by-id/*/log.qslog).
Steps to reproduce
- Clone the menu plugin:
omarchy plugin clone omarchy.menu(id becomes<user>.menu, e.g.gr4vty.menu). The bar switches to the clone andomarchy.menuis disabled. - Restart the shell:
omarchy restart shell. - Open the menu (Super+Space / bar button) and navigate to Apps.
- Observe: the Apps submenu is empty. (Cross-check: the built-in
omarchy.menushows apps.)
Diagnostics gathered
DesktopEntriesscans all apps successfully at shell startup regardless of plugin
(Found desktop entry ... for ~94 system+user apps) — the app source is not the problem.
- The clone's code is byte-identical to the first-party plugin except:
- its manifest id (gr4vty.menu vs omarchy.menu), and
- the omarchy.clonedFrom: "omarchy.menu" marker.
- A fresh re-clone (omarchy plugin remove gr4vty.menu --yes && omarchy plugin clone omarchy.menu) still reproduces the empty Apps submenu.
- Instrumenting Menu.qml mergeAppRows() with a console.log at its first line shows the function never executes for the clone when the Apps route is opened (no output in the log), whereas the first-party menu populates rows. So the failure is silent and upstream of mergeAppRows / root.appLibrary.
Suspected root cause
Clones of a menu-kind plugin are wired through the scoped PluginAppLibraryApi
(pluginAppLibraryFor(...) in shell.qml), while first-party menu plugins receive
the full shell (pluginShellFor returns the real shell for __isFirstParty) and read
the real AppLibrary via shell.appLibrary. For cloned menus the scoped app-library
path never delivers rows, so root.appLibrary.sortedEntries("") yields an empty list
(or root.appLibrary resolves in a way that keeps mergeAppRows from running).
Relevant source (read-only, /usr/share/omarchy/shell/):
- shell.qml: pluginAppLibraryFor (~L423), createScopedPluginShell appLibrary wiring (~L601-604), pluginShellFor first-party short-circuit (~L739).
- services/PluginAppLibraryApi.qml: sortedEntries returns _sortedEntries(...).
- services/AppSearch.js / services/AppLibrary.qml: the real entry source.
Impact
Any user cloning omarchy.menu for customization (very common, since the docs
recommend cloning rather than editing /usr/share/omarchy/) loses the Apps launcher.
View raw text
**Omarchy version:** 4.0.3-1 (Arch Linux, Hyprland, Quickshell shell)
## Summary
Cloning the first-party `omarchy.menu` plugin with `omarchy plugin clone omarchy.menu`
(which creates `~/.config/omarchy/plugins/<user>.menu/`) produces a menu whose
**Apps submenu is empty** — no application rows are ever populated. The built-in
first-party `omarchy.menu` shows all applications correctly. Re-cloning a fresh,
byte-identical copy does not fix it.
## Expected
The cloned menu should populate the Apps submenu with the same desktop entries as
the built-in `omarchy.menu`.
## Actual
The Apps submenu renders with zero rows. No error is printed to the Quickshell
log (`/run/user/<uid>/quickshell/by-id/*/log.qslog`).
## Steps to reproduce
1. Clone the menu plugin: `omarchy plugin clone omarchy.menu` (id becomes `<user>.menu`, e.g. `gr4vty.menu`). The bar switches to the clone and `omarchy.menu` is disabled.
2. Restart the shell: `omarchy restart shell`.
3. Open the menu (Super+Space / bar button) and navigate to **Apps**.
4. Observe: the Apps submenu is empty. (Cross-check: the built-in `omarchy.menu` shows apps.)
## Diagnostics gathered
- `DesktopEntries` scans all apps successfully at shell startup regardless of plugin
(`Found desktop entry ...` for ~94 system+user apps) — the app source is not the problem.
- The clone's code is **byte-identical** to the first-party plugin except:
- its manifest `id` (`gr4vty.menu` vs `omarchy.menu`), and
- the `omarchy.clonedFrom: "omarchy.menu"` marker.
- A fresh re-clone (`omarchy plugin remove gr4vty.menu --yes && omarchy plugin clone omarchy.menu`) still reproduces the empty Apps submenu.
- Instrumenting `Menu.qml` `mergeAppRows()` with a `console.log` at its first line shows the function **never executes** for the clone when the Apps route is opened (no output in the log), whereas the first-party menu populates rows. So the failure is silent and upstream of `mergeAppRows` / `root.appLibrary`.
## Suspected root cause
Clones of a `menu`-kind plugin are wired through the scoped `PluginAppLibraryApi`
(`pluginAppLibraryFor(...)` in `shell.qml`), while first-party `menu` plugins receive
the full shell (`pluginShellFor` returns the real shell for `__isFirstParty`) and read
the real `AppLibrary` via `shell.appLibrary`. For cloned menus the scoped app-library
path never delivers rows, so `root.appLibrary.sortedEntries("")` yields an empty list
(or `root.appLibrary` resolves in a way that keeps `mergeAppRows` from running).
Relevant source (read-only, `/usr/share/omarchy/shell/`):
- `shell.qml`: `pluginAppLibraryFor` (~L423), `createScopedPluginShell` appLibrary wiring (~L601-604), `pluginShellFor` first-party short-circuit (~L739).
- `services/PluginAppLibraryApi.qml`: `sortedEntries` returns `_sortedEntries(...)`.
- `services/AppSearch.js` / `services/AppLibrary.qml`: the real entry source.
## Impact
Any user cloning `omarchy.menu` for customization (very common, since the docs
recommend cloning rather than editing `/usr/share/omarchy/`) loses the Apps launcher.
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.