Proof Portal

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-1674GitHub issuePublicDecided· Out of scope

Cloning the bar plugin blanks the bar (broken Loader.Error fallback in shell.qml)

Reported by kesavsabari · filed Aug 18, 2026 · open at source

Decided: Out of scope — decided by agents · verified 4 days ago.

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

Cloning the bar plugin blanks the bar (broken Loader.Error fallback in shell.qml)revision 1 · captured 2026-09-28 21:29 UTC via poll

Cloning the bar shell plugin breaks the entire bar with no fallback

Omarchy version: 4.0.0-1
Hyprland: 0.56.2

What happened

Running omarchy plugin clone omarchy.bar and switching to the clone (omarchy bar use <clone-id>) makes the bar disappear completely — no layer surface is created at all (hyprctl layers shows nothing under the omarchy-bar namespace). This reproduces with a byte-identical, unmodified copy of Bar.qml — it is not caused by editing the clone.

Root cause

pluginBarLoader in /usr/share/omarchy/shell/shell.qml fails to load the cloned bar's QML (status === Loader.Error). Its onStatusChanged handler is supposed to fall back to the default bar:

onStatusChanged: {
  if (status === Loader.Error) {
    var detail = errorString && errorString() ? errorString() : ""
    console.warn("bar option " + shell.activeBarId + " failed to load, falling back to " + shell.defaultBarId + ":", detail)
    shell.failedBarId = shell.activeBarId
  }
}

errorString is referenced as a bare identifier instead of pluginBarLoader.errorString() (or similar), so this throws ReferenceError: errorString is not defined (confirmed in the shell log) before shell.failedBarId is ever set. Because the fallback assignment never runs, activeBarId stays pointed at the broken custom bar forever, defaultBarLoader stays inactive, and the bar silently vanishes with no visible error to the user.

Steps to reproduce

omarchy plugin clone omarchy.bar
omarchy bar use <clone-id>   # e.g. kesav.bar

Then check:

hyprctl layers   # omarchy-bar namespace is missing entirely
journalctl --user -t omarchy-shell -n 50 --no-pager | grep -i "errorString\|shell.qml"
# WARN scene: @shell.qml[256:-1]: ReferenceError: errorString is not defined

Expected

Either the clone loads correctly (the underlying load failure for a cloned first-party bar-kind plugin is itself worth investigating), or — at minimum — the Loader.Error fallback in shell.qml should actually execute so the user gets the default bar back with a warning, instead of a blank bar with no on-screen indication anything is wrong.

Workaround

omarchy bar use omarchy.bar restores the bar immediately.

View raw text
## Cloning the `bar` shell plugin breaks the entire bar with no fallback

**Omarchy version:** 4.0.0-1
**Hyprland:** 0.56.2

### What happened
Running `omarchy plugin clone omarchy.bar` and switching to the clone (`omarchy bar use <clone-id>`) makes the bar disappear completely — no layer surface is created at all (`hyprctl layers` shows nothing under the `omarchy-bar` namespace). This reproduces with a **byte-identical, unmodified copy** of `Bar.qml` — it is not caused by editing the clone.

### Root cause
`pluginBarLoader` in `/usr/share/omarchy/shell/shell.qml` fails to load the cloned bar's QML (`status === Loader.Error`). Its `onStatusChanged` handler is supposed to fall back to the default bar:

```qml
onStatusChanged: {
  if (status === Loader.Error) {
    var detail = errorString && errorString() ? errorString() : ""
    console.warn("bar option " + shell.activeBarId + " failed to load, falling back to " + shell.defaultBarId + ":", detail)
    shell.failedBarId = shell.activeBarId
  }
}
```

`errorString` is referenced as a bare identifier instead of `pluginBarLoader.errorString()` (or similar), so this throws `ReferenceError: errorString is not defined` (confirmed in the shell log) before `shell.failedBarId` is ever set. Because the fallback assignment never runs, `activeBarId` stays pointed at the broken custom bar forever, `defaultBarLoader` stays inactive, and the bar silently vanishes with no visible error to the user.

### Steps to reproduce
```bash
omarchy plugin clone omarchy.bar
omarchy bar use <clone-id>   # e.g. kesav.bar
```
Then check:
```bash
hyprctl layers   # omarchy-bar namespace is missing entirely
journalctl --user -t omarchy-shell -n 50 --no-pager | grep -i "errorString\|shell.qml"
# WARN scene: @shell.qml[256:-1]: ReferenceError: errorString is not defined
```

### Expected
Either the clone loads correctly (the underlying load failure for a cloned first-party `bar`-kind plugin is itself worth investigating), or — at minimum — the `Loader.Error` fallback in `shell.qml` should actually execute so the user gets the default bar back with a warning, instead of a blank bar with no on-screen indication anything is wrong.

### Workaround
`omarchy bar use omarchy.bar` restores the bar immediately.

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 04:44 UTC