Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-5042GitHub issuePublicReceived

Cloning the menu plugin breaks the Apps submenu (appLibrary not wired for cloned menu plugins in 4.0.3)

Reported by RubenMovsesyan · filed Sep 12, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #10661 (R-860). GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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

Cloning the menu plugin breaks the Apps submenu (appLibrary not wired for cloned menu plugins in 4.0.3)revision 1 · captured 2026-10-04 12:10 UTC via poll

System details

AMD Ryzen 9 9950X3D, NVIDIA RTX 4080 SUPER, Omarchy 4.0.3-1

What's wrong?

After updating from Omarchy 4.0.2 to 4.0.3, every app in the Omarchy menu's "Apps" submenu disappeared for anyone using a cloned copy of the menu plugin (omarchy plugin clone omarchy.menu). This affects the stock/default menu setup too if you clone it — it is not specific to an old or customized clone.

Root cause: 4.0.3 added a plugin capability/sandboxing system to shell/shell.qml (createScopedPluginShell, pluginShellFor, PluginShellApi, etc.). For a first-party plugin, pluginShellFor() hands the panel the real shell object directly (which has a working appLibrary property backed by Quickshell's DesktopEntries). For any non-first-party ("cloned") plugin, it instead builds a scoped proxy via createScopedPluginShell(). For a cloned menu-kind plugin specifically, that proxy never reaches the panel: the cloned Menu.qml's shell property comes back null at runtime, so Menu.qml's appLibrary getter (root.shell ? root.shell.appLibrary : null) is always null, and the Apps submenu's mergeAppRows() bails out immediately (if (!root.appLibrary) return), leaving the Apps list permanently empty. No warning or error is logged anywhere (journal, or Quickshell's own verbose log with *=true rules) — it just fails silently.

Other rows in the menu (JSONC-defined items, bash-script providers) are unaffected, since they don't depend on appLibrary. Only the QML-native apps provider breaks.

Steps to reproduce

  1. On Omarchy 4.0.3, run omarchy plugin clone omarchy.menu (creates ~/.config/omarchy/plugins/<user>.menu/ and switches the bar to it).
  2. Restart the shell: omarchy restart shell.
  3. Open the menu and navigate to Apps.
  4. The Apps submenu is empty, even though ~/.local/share/applications and /usr/share/applications are fully populated.

I confirmed this is not content-specific by cloning fresh (no edits at all) and hitting the exact same failure, and confirmed it's the shell/appLibrary wiring specifically (not desktop-entry discovery) by adding a temporary debug probe to the cloned Menu.qml and querying it live over Quickshell's IPC (quickshell ipc call shell call <id> <method> <arg>):

  • Stock omarchy.menu (not cloned): root.shell is a valid object, Apps submenu shows all 46 installed apps.
  • Any clone of omarchy.menu (old or brand new): root.shell is null, Apps submenu shows 0 entries.

Workaround

Switch the bar back to the stock omarchy.menu (disable the clone in ~/.config/omarchy/shell.json's disabledPlugins/bar layout). This restores the Apps list but loses any customization made in the clone.

Expected behavior

Cloning omarchy.menu (or any menu-kind plugin) should preserve full Apps functionality, the same as the stock plugin.

View raw text
### System details
AMD Ryzen 9 9950X3D, NVIDIA RTX 4080 SUPER, Omarchy 4.0.3-1

### What's wrong?

After updating from Omarchy 4.0.2 to 4.0.3, every app in the Omarchy menu's "Apps" submenu disappeared for anyone using a **cloned** copy of the menu plugin (`omarchy plugin clone omarchy.menu`). This affects the stock/default menu setup too if you clone it — it is not specific to an old or customized clone.

**Root cause:** 4.0.3 added a plugin capability/sandboxing system to `shell/shell.qml` (`createScopedPluginShell`, `pluginShellFor`, `PluginShellApi`, etc.). For a first-party plugin, `pluginShellFor()` hands the panel the real `shell` object directly (which has a working `appLibrary` property backed by Quickshell's `DesktopEntries`). For any non-first-party ("cloned") plugin, it instead builds a scoped proxy via `createScopedPluginShell()`. For a cloned **menu**-kind plugin specifically, that proxy never reaches the panel: the cloned `Menu.qml`'s `shell` property comes back `null` at runtime, so `Menu.qml`'s `appLibrary` getter (`root.shell ? root.shell.appLibrary : null`) is always `null`, and the Apps submenu's `mergeAppRows()` bails out immediately (`if (!root.appLibrary) return`), leaving the Apps list permanently empty. No warning or error is logged anywhere (journal, or Quickshell's own verbose log with `*=true` rules) — it just fails silently.

Other rows in the menu (JSONC-defined items, bash-script `provider`s) are unaffected, since they don't depend on `appLibrary`. Only the QML-native `apps` provider breaks.

### Steps to reproduce

1. On Omarchy 4.0.3, run `omarchy plugin clone omarchy.menu` (creates `~/.config/omarchy/plugins/<user>.menu/` and switches the bar to it).
2. Restart the shell: `omarchy restart shell`.
3. Open the menu and navigate to **Apps**.
4. The Apps submenu is empty, even though `~/.local/share/applications` and `/usr/share/applications` are fully populated.

I confirmed this is not content-specific by cloning fresh (no edits at all) and hitting the exact same failure, and confirmed it's the `shell`/`appLibrary` wiring specifically (not desktop-entry discovery) by adding a temporary debug probe to the cloned `Menu.qml` and querying it live over Quickshell's IPC (`quickshell ipc call shell call <id> <method> <arg>`):

- Stock `omarchy.menu` (not cloned): `root.shell` is a valid object, Apps submenu shows all 46 installed apps.
- Any clone of `omarchy.menu` (old or brand new): `root.shell` is `null`, Apps submenu shows 0 entries.

### Workaround

Switch the bar back to the stock `omarchy.menu` (disable the clone in `~/.config/omarchy/shell.json`'s `disabledPlugins`/bar layout). This restores the Apps list but loses any customization made in the clone.

### Expected behavior

Cloning `omarchy.menu` (or any menu-kind plugin) should preserve full Apps functionality, the same as the stock plugin.

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.