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 bar plugin (omarchy plugin clone omarchy.bar) breaks the bar on every monitor
Reported by fallendown · filed Aug 15, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #6915 (R-1851). 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 built-in bar plugin with omarchy plugin clone omarchy.bar produces
a plugin that fails to load, taking the bar down entirely on every monitor
(not just the clone's target monitor).
What I expected
The clone (<user>.bar) should render identically to the stock omarchy.bar it
was copied from, since omarchy plugin clone is the documented way to
customize built-in bar/plugin QML.
Steps to reproduce
omarchy plugin clone omarchy.bar
omarchy restart shellNo edits to the cloned file are needed — even a byte-for-byte unmodified copy
of plugins/bar/Bar.qml reproduces the failure.
Observed behavior
omarchy-plugin-list --jsonreports the clone as"enabled": true, "active": true.hyprctl layersshows noomarchy-barnamespace surface on any monitor —
the bar is completely gone.
- The shell log shows:
WARN scene: file:///home/<user>/.config/omarchy/plugins/<user>.bar/Bar.qml[15:3]: Required property omarchyPath was not initialized
WARN scene: file:///home/<user>/.config/omarchy/plugins/<user>.bar/Bar.qml[17:3]: Required property barWidgetRegistry was not initialized
WARN scene: file:///home/<user>/.config/omarchy/plugins/<user>.bar/Bar.qml[22:3]: Required property barConfig was not initialized
WARN scene: @shell.qml[256:-1]: ReferenceError: errorString is not defined The last line looks like a secondary bug in shell.qml's own error-handling
path (referencing errorString instead of the Loader's errorString()),
which masks whatever the real underlying QML load error is.
Workaround
omarchy plugin remove <user>.bar --yes restores the stock omarchy.bar and
the bar reappears on all monitors.
System details
- Omarchy version: 4.0.0-1
- Hyprland: 0.56.2 (v0.56.2, commit efb50993)
- Quickshell: 0.3.0 (AUR quickshell-git, revision 28771c7c)
- GPU: NVIDIA RTX 4070 SUPER (nvidia 610.57.04) + AMD Raphael iGPU (amdgpu)
- Display: Wayland, 2 monitors (2560x1440 + 1920x1080)
- Note:
omarchy debug --no-sudo --printreferenced in the skill docs does not
exist as a command on this Omarchy version (checked omarchy commands --all).
Context this came up in
Trying to make the bar render on only one of two monitors (no monitor
restriction exists in shell.json), which requires cloning the bar plugin per
Omarchy's own customization docs. The clone-loading bug blocks that path
entirely.
View raw text
## What happened Cloning the built-in bar plugin with `omarchy plugin clone omarchy.bar` produces a plugin that fails to load, taking the bar down entirely on **every** monitor (not just the clone's target monitor). ## What I expected The clone (`<user>.bar`) should render identically to the stock `omarchy.bar` it was copied from, since `omarchy plugin clone` is the documented way to customize built-in bar/plugin QML. ## Steps to reproduce ``` omarchy plugin clone omarchy.bar omarchy restart shell ``` No edits to the cloned file are needed — even a byte-for-byte unmodified copy of `plugins/bar/Bar.qml` reproduces the failure. ## Observed behavior - `omarchy-plugin-list --json` reports the clone as `"enabled": true, "active": true`. - `hyprctl layers` shows no `omarchy-bar` namespace surface on any monitor — the bar is completely gone. - The shell log shows: ``` WARN scene: file:///home/<user>/.config/omarchy/plugins/<user>.bar/Bar.qml[15:3]: Required property omarchyPath was not initialized WARN scene: file:///home/<user>/.config/omarchy/plugins/<user>.bar/Bar.qml[17:3]: Required property barWidgetRegistry was not initialized WARN scene: file:///home/<user>/.config/omarchy/plugins/<user>.bar/Bar.qml[22:3]: Required property barConfig was not initialized WARN scene: @shell.qml[256:-1]: ReferenceError: errorString is not defined ``` The last line looks like a secondary bug in shell.qml's own error-handling path (referencing `errorString` instead of the Loader's `errorString()`), which masks whatever the real underlying QML load error is. ## Workaround `omarchy plugin remove <user>.bar --yes` restores the stock `omarchy.bar` and the bar reappears on all monitors. ## System details - Omarchy version: 4.0.0-1 - Hyprland: 0.56.2 (v0.56.2, commit efb50993) - Quickshell: 0.3.0 (AUR quickshell-git, revision 28771c7c) - GPU: NVIDIA RTX 4070 SUPER (nvidia 610.57.04) + AMD Raphael iGPU (amdgpu) - Display: Wayland, 2 monitors (2560x1440 + 1920x1080) - Note: `omarchy debug --no-sudo --print` referenced in the skill docs does not exist as a command on this Omarchy version (checked `omarchy commands --all`). ## Context this came up in Trying to make the bar render on only one of two monitors (no monitor restriction exists in `shell.json`), which requires cloning the bar plugin per Omarchy's own customization docs. The clone-loading bug blocks that path entirely.
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.