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 the omarchy.background service plugin fails to load (No such file or directory)
Reported by henriquelopeslima · filed Sep 22, 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?
- AreaOutside the audited area· Decided by agents · verified
- 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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
What happened
Running omarchy plugin clone omarchy.background (even with zero edits to the cloned file) produces a clone that never actually loads. The Quickshell log repeatedly shows:
WARN qml: service plugin load failed for <user>.background: file:///home/<user>/.config/omarchy/plugins/<user>.background/Background.qml: No such file or directory...even though the file exists at that exact path with normal permissions (verified with stat/ls while the error kept recurring). omarchy plugin list --json reports the clone as "enabled": true, but no omarchy-background wlr-layer-shell surface is ever created for it (hyprctl layers shows nothing at layer 0 for any monitor) until the original omarchy.background plugin is re-enabled.
Expected
omarchy plugin clone omarchy.background should produce a working clone that renders identically to the built-in plugin — the way cloning a bar-widget plugin (e.g. omarchy plugin clone omarchy.keyboard-layout) works fine.
Steps to reproduce
omarchy plugin clone omarchy.background- Tail the Quickshell log (
$XDG_RUNTIME_DIR/quickshell/by-id/*/log.log), or runomarchy plugin list --json | jq '.[] | select(.id|test("background"))'andhyprctl layers -j. - The clone shows
"enabled": true, but the log repeatsservice plugin load failed for <id>: ...Background.qml: No such file or directory, and no per-monitoromarchy-backgroundlayer surface exists for it. - Re-enabling the original
omarchy.backgroundplugin (omarchy plugin enable omarchy.background) restores a working background immediately.
Notes
- Reproduced identically with (a) an unmodified clone and (b) a clone with a small edit (added a per-monitor wallpaper override in
Background.qml) — same failure either way, so the edit isn't the cause. - Cloning a
bar-widget-kind plugin (omarchy.keyboard-layout) worked without any issue, so this looks specific toservice-kind plugins that useQuickshell.Wayland/WlrLayershell(background layer). - After a few
enable/disable/clone cycles while investigating, one monitor (HDMI-A-1) ended up with twoomarchy-backgroundlayer surfaces simultaneously (harmless duplicate; cleared byomarchy restart shell). - No workaround needed on my end — reverted to the stock
omarchy.backgroundplugin, which works normally.
System
- Omarchy 4.0.4-1
- Hyprland 0.56.2-2
- Quickshell 0.3.1-1
- Kernel 7.2.5-3-omarchy
- 3-monitor Hyprland setup (internal laptop panel + 2 external displays, mixed resolutions/refresh rates)
View raw text
## What happened
Running `omarchy plugin clone omarchy.background` (even with zero edits to the cloned file) produces a clone that never actually loads. The Quickshell log repeatedly shows:
```
WARN qml: service plugin load failed for <user>.background: file:///home/<user>/.config/omarchy/plugins/<user>.background/Background.qml: No such file or directory
```
...even though the file exists at that exact path with normal permissions (verified with `stat`/`ls` while the error kept recurring). `omarchy plugin list --json` reports the clone as `"enabled": true`, but no `omarchy-background` wlr-layer-shell surface is ever created for it (`hyprctl layers` shows nothing at layer 0 for any monitor) until the original `omarchy.background` plugin is re-enabled.
## Expected
`omarchy plugin clone omarchy.background` should produce a working clone that renders identically to the built-in plugin — the way cloning a `bar-widget` plugin (e.g. `omarchy plugin clone omarchy.keyboard-layout`) works fine.
## Steps to reproduce
1. `omarchy plugin clone omarchy.background`
2. Tail the Quickshell log (`$XDG_RUNTIME_DIR/quickshell/by-id/*/log.log`), or run `omarchy plugin list --json | jq '.[] | select(.id|test("background"))'` and `hyprctl layers -j`.
3. The clone shows `"enabled": true`, but the log repeats `service plugin load failed for <id>: ...Background.qml: No such file or directory`, and no per-monitor `omarchy-background` layer surface exists for it.
4. Re-enabling the original `omarchy.background` plugin (`omarchy plugin enable omarchy.background`) restores a working background immediately.
## Notes
- Reproduced identically with (a) an unmodified clone and (b) a clone with a small edit (added a per-monitor wallpaper override in `Background.qml`) — same failure either way, so the edit isn't the cause.
- Cloning a `bar-widget`-kind plugin (`omarchy.keyboard-layout`) worked without any issue, so this looks specific to `service`-kind plugins that use `Quickshell.Wayland`/`WlrLayershell` (background layer).
- After a few `enable`/`disable`/clone cycles while investigating, one monitor (`HDMI-A-1`) ended up with two `omarchy-background` layer surfaces simultaneously (harmless duplicate; cleared by `omarchy restart shell`).
- No workaround needed on my end — reverted to the stock `omarchy.background` plugin, which works normally.
## System
- Omarchy 4.0.4-1
- Hyprland 0.56.2-2
- Quickshell 0.3.1-1
- Kernel 7.2.5-3-omarchy
- 3-monitor Hyprland setup (internal laptop panel + 2 external displays, mixed resolutions/refresh rates)
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.
- Out of scopeDecided by agents · verified · 2026-10-09 17:31 UTC