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.
Bar-kind plugin clones never mount: required properties not initialized
Reported by lvkz · filed Aug 15, 2026Closed upstream on 2026-08-15 by dhh, as a duplicate of #6915 (R-1851). GitHub close reason: not_planned.
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
Summary
Cloning the bar plugin (omarchy plugin clone omarchy.bar) produces a shell with no bar on any screen. The cloned bar is instantiated without its required properties, so it never mounts. This also affects an unmodified, pristine clone — no user edits are needed to reproduce — and it makes the documented alternative-bar flow (omarchy bar use <id>, e.g. the local.neon-bar example in the bar plugin README) unusable.
Environment
- omarchy
4.0.0-1(fresh upgrade to Quattro) - hyprland
0.56.2-1 - quickshell-git
0.3.0.r20.g28771c7-1
Steps to reproduce
omarchy plugin clone omarchy.bar(clones to~/.config/omarchy/plugins/<user>.barand auto-switches the bar to the clone)omarchy restart shell
Expected
The cloned bar renders identically to omarchy.bar (it is a byte-for-byte copy with only the manifest id rewritten).
Actual
No bar renders on any screen. The journal shows the clone being instantiated without the required properties the host normally injects:
WARN scene: file:///home/lvkz/.config/omarchy/plugins/lvkz.bar/Bar.qml[15:3]: Required property omarchyPath was not initialized
WARN scene: file:///home/lvkz/.config/omarchy/plugins/lvkz.bar/Bar.qml[17:3]: Required property barWidgetRegistry was not initialized
WARN scene: file:///home/lvkz/.config/omarchy/plugins/lvkz.bar/Bar.qml[22:3]: Required property barConfig was not initialized
WARN scene: @shell.qml[256:-1]: ReferenceError: errorString is not definedThe warnings appear once per screen (6 lines on a 2-monitor setup). Widget-kind clones (omarchy plugin clone omarchy.workspaces, omarchy.weather) mount fine on the same system, so this looks specific to the bar kind: the first-party mount path passes omarchyPath / barWidgetRegistry / barConfig, but the path used for user plugins apparently does not.
Secondary issue
The last log line suggests the shell's plugin-load error handler references an undefined errorString (shell.qml line 256), so whatever diagnostic it meant to surface is lost.
Recovery (works)
omarchy plugin remove <user>.bar --yes # prints "Restored omarchy.bar."
omarchy restart shellplus removing the leftover "id": "<user>.bar" key from bar in ~/.config/omarchy/shell.json if present.
Why I hit this
I was porting a pre-Quattro per-monitor Waybar setup (no bar on one specific monitor) and cloned the bar to add a screen filter — then found even the pristine clone doesn't mount.
View raw text
## Summary Cloning the bar plugin (`omarchy plugin clone omarchy.bar`) produces a shell with **no bar on any screen**. The cloned bar is instantiated without its required properties, so it never mounts. This also affects an unmodified, pristine clone — no user edits are needed to reproduce — and it makes the documented alternative-bar flow (`omarchy bar use <id>`, e.g. the `local.neon-bar` example in the bar plugin README) unusable. ## Environment - omarchy `4.0.0-1` (fresh upgrade to Quattro) - hyprland `0.56.2-1` - quickshell-git `0.3.0.r20.g28771c7-1` ## Steps to reproduce 1. `omarchy plugin clone omarchy.bar` (clones to `~/.config/omarchy/plugins/<user>.bar` and auto-switches the bar to the clone) 2. `omarchy restart shell` ## Expected The cloned bar renders identically to `omarchy.bar` (it is a byte-for-byte copy with only the manifest id rewritten). ## Actual No bar renders on any screen. The journal shows the clone being instantiated without the required properties the host normally injects: ``` WARN scene: file:///home/lvkz/.config/omarchy/plugins/lvkz.bar/Bar.qml[15:3]: Required property omarchyPath was not initialized WARN scene: file:///home/lvkz/.config/omarchy/plugins/lvkz.bar/Bar.qml[17:3]: Required property barWidgetRegistry was not initialized WARN scene: file:///home/lvkz/.config/omarchy/plugins/lvkz.bar/Bar.qml[22:3]: Required property barConfig was not initialized WARN scene: @shell.qml[256:-1]: ReferenceError: errorString is not defined ``` The warnings appear once per screen (6 lines on a 2-monitor setup). Widget-kind clones (`omarchy plugin clone omarchy.workspaces`, `omarchy.weather`) mount fine on the same system, so this looks specific to the `bar` kind: the first-party mount path passes `omarchyPath` / `barWidgetRegistry` / `barConfig`, but the path used for user plugins apparently does not. ## Secondary issue The last log line suggests the shell's plugin-load error handler references an undefined `errorString` (`shell.qml` line 256), so whatever diagnostic it meant to surface is lost. ## Recovery (works) ``` omarchy plugin remove <user>.bar --yes # prints "Restored omarchy.bar." omarchy restart shell ``` plus removing the leftover `"id": "<user>.bar"` key from `bar` in `~/.config/omarchy/shell.json` if present. ## Why I hit this I was porting a pre-Quattro per-monitor Waybar setup (no bar on one specific monitor) and cloned the bar to add a screen filter — then found even the pristine clone doesn't mount.
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.