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 built-in bar leaves no bar: Loader.Error handler throws ReferenceError, skipping the default-bar fallback
Reported by james-engelbrecht · filed Sep 8, 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
System details
AMD Ryzen 7 5800H, NVIDIA RTX 3060 Mobile, Omarchy 4.0.2-1, kernel 7.1.9-arch1-2, quickshell 0.3.1
What's wrong?
omarchy plugin clone omarchy.bar (the documented customization path) leaves the user with no bar at all, silently, and without the intended fallback to the default bar.
Steps to reproduce
- On Omarchy 4.0.2-1, run
omarchy plugin clone omarchy.bar. - The shell switches
bar.idto the clone and reloads. - The bar disappears entirely; journal shows:
WARN scene: Bar.qml[15:3]: Required property omarchyPath was not initialized
WARN scene: Bar.qml[22:3]: Required property barConfig was not initialized
WARN scene: Bar.qml[17:3]: Required property barWidgetRegistry was not initialized
WARN scene: shell.qml[256:-1]: ReferenceError: errorString is not definedCause — two stacked bugs
pluginBarLoader(shell.qml) loads plugin bar entry points withsource:and injectsomarchyPath/barConfig/barWidgetRegistryonly inonLoaded. But the built-in bar's root declares those asrequired property, and QML fails component creation when required properties are not provided at creation time. The loader lands inLoader.Error.- The loader's
onStatusChangedreadserrorStringunqualified. Not every Qt/quickshell build exposesLoader.errorString, so the reference throwsReferenceErrorinside the handler, which aborts it beforeconsole.warnandshell.failedBarId = shell.activeBarIdrun. The failedBarId fallback (activeBarId falls back toomarchy.bar) therefore never engages, and the shell is left withshell.bar = null— no bar, no fallback.
Status on current HEAD
I checked quattro HEAD: the bar loader's onStatusChanged no longer touches errorString, and shell/plugins/bar/Bar.qml now declares the three host-injected properties as optional with defaults (omarchyPath: Quickshell.env("OMARCHY_PATH"), barWidgetRegistry: fallbackBarWidgetRegistry, barConfig: ({})) — so this specific chain appears fixed upstream already, and 4.0.2-1 users just need an update.
Remaining instance of the same bug
The panel loader in shell.qml still uses the same unguarded pattern:
var detail = errorString && errorString() ? errorString() : ""If a panel plugin fails to load on a build without Loader.errorString, the handler throws before console.warn and shell.hide() run — a failed panel silently refuses to open with no signal. I will open a PR guarding that call with typeof.
View raw text
### System details
AMD Ryzen 7 5800H, NVIDIA RTX 3060 Mobile, Omarchy 4.0.2-1, kernel 7.1.9-arch1-2, quickshell 0.3.1
### What's wrong?
`omarchy plugin clone omarchy.bar` (the documented customization path) leaves the user with **no bar at all**, silently, and without the intended fallback to the default bar.
**Steps to reproduce**
1. On Omarchy 4.0.2-1, run `omarchy plugin clone omarchy.bar`.
2. The shell switches `bar.id` to the clone and reloads.
3. The bar disappears entirely; journal shows:
```
WARN scene: Bar.qml[15:3]: Required property omarchyPath was not initialized
WARN scene: Bar.qml[22:3]: Required property barConfig was not initialized
WARN scene: Bar.qml[17:3]: Required property barWidgetRegistry was not initialized
WARN scene: shell.qml[256:-1]: ReferenceError: errorString is not defined
```
**Cause — two stacked bugs**
1. `pluginBarLoader` (shell.qml) loads plugin bar entry points with `source:` and injects `omarchyPath`/`barConfig`/`barWidgetRegistry` only in `onLoaded`. But the built-in bar's root declares those as `required property`, and QML fails component creation when required properties are not provided at creation time. The loader lands in `Loader.Error`.
2. The loader's `onStatusChanged` reads `errorString` unqualified. Not every Qt/quickshell build exposes `Loader.errorString`, so the reference throws `ReferenceError` *inside the handler*, which aborts it before `console.warn` and `shell.failedBarId = shell.activeBarId` run. The failedBarId fallback (activeBarId falls back to `omarchy.bar`) therefore never engages, and the shell is left with `shell.bar = null` — no bar, no fallback.
**Status on current HEAD**
I checked `quattro` HEAD: the bar loader's `onStatusChanged` no longer touches `errorString`, and `shell/plugins/bar/Bar.qml` now declares the three host-injected properties as optional with defaults (`omarchyPath: Quickshell.env("OMARCHY_PATH")`, `barWidgetRegistry: fallbackBarWidgetRegistry`, `barConfig: ({})`) — so this specific chain appears fixed upstream already, and 4.0.2-1 users just need an update.
**Remaining instance of the same bug**
The *panel* loader in shell.qml still uses the same unguarded pattern:
```qml
var detail = errorString && errorString() ? errorString() : ""
```
If a panel plugin fails to load on a build without `Loader.errorString`, the handler throws before `console.warn` and `shell.hide()` run — a failed panel silently refuses to open with no signal. I will open a PR guarding that call with `typeof`.
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.