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.
omarchy toggle bar on hides the bar instead of showing it
Reported by evgen867777-coder · filed Sep 30, 2026 · 2 revisionsClosed upstream on 2026-10-13 by the bot omarchybot, as a duplicate (target not recorded).
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
Summary
omarchy toggle bar on produces the opposite of what the command name says.
Running it hides the menu bar; omarchy toggle bar off shows it.
Steps to reproduce
omarchy toggle bar on
hyprctl layers | grep omarchy-barActual
The omarchy-bar layer is still mapped, but parked above the top edge of the
screen:
Layer 59654db57d60: xywh: 0 -26 1920 26, a: 1, namespace: omarchy-bar
^^^ negative YExpected
omarchy toggle bar on should leave the bar visible at 0 0.
Cause
/usr/share/omarchy/bin/omarchy-toggle-bar forwards its argument unchanged:
omarchy-toggle bar-off "${1:-toggle}"and omarchy-toggle implements on as "create the flag file":
enable() {
mkdir -p "$(dirname "$FLAG")"
touch "$FLAG"
}Meanwhile the bar treats the presence of that flag as "hidden"
(/usr/share/omarchy/shell/plugins/bar/Bar.qml:1171):
command: ["bash", "-c", "[[ -f $HOME/.local/state/omarchy/toggles/bar-off ]] && echo yes || echo no"]So the flag name already encodes the inverted sense — bar-off — and the
generic on/off actions then apply it the wrong way round:
| Command | toggles/bar-off | Bar |
|---|---|---|
omarchy toggle bar on | created | hidden |
omarchy toggle bar off | removed | visible |
Impact
The documented way to bring the bar back is inverted. A user who runsomarchy toggle bar on to recover a missing bar gets no visible change, andomarchy toggle bar then appears to be a no-op. The desktop looks broken with
no obvious way back except reading Bar.qml to find the flag name.
Notes
omarchy-toggle is generic, so it cannot be fixed by swapping on and off
there — that would invert every other toggle (idle-lock, notifications,crash-capture, screensaver, nightlight, battery-percentage,workspace-layout, window-gaps, one-window-ratio). Every other consumer
already treats a present flag as "feature on", so bar-off looks like the
odd one out.
Suggested direction, whichever is chosen:
- Rename the flag to
bar-hiddenand haveomarchy-toggle-barmap
on -> remove, off -> create. Keeps omarchy-toggle generic.
2. Or keep bar-off and translate inside omarchy-toggle-bar.
Option 1 also matches the comment already in Bar.qml:38.
Migration concern for option 1: an existing toggles/bar-off file would be
ignored, so the bar would pop back into view once on upgrade. Probably fine,
but worth a note.
Environment
- Omarchy 4.0.4-1
- Host
Legend
View raw text
## Summary
`omarchy toggle bar on` produces the opposite of what the command name says.
Running it hides the menu bar; `omarchy toggle bar off` shows it.
## Steps to reproduce
```bash
omarchy toggle bar on
hyprctl layers | grep omarchy-bar
```
## Actual
The `omarchy-bar` layer is still mapped, but parked above the top edge of the
screen:
```
Layer 59654db57d60: xywh: 0 -26 1920 26, a: 1, namespace: omarchy-bar
^^^ negative Y
```
## Expected
`omarchy toggle bar on` should leave the bar visible at `0 0`.
## Cause
`/usr/share/omarchy/bin/omarchy-toggle-bar` forwards its argument unchanged:
```bash
omarchy-toggle bar-off "${1:-toggle}"
```
and `omarchy-toggle` implements `on` as "create the flag file":
```bash
enable() {
mkdir -p "$(dirname "$FLAG")"
touch "$FLAG"
}
```
Meanwhile the bar treats the *presence* of that flag as "hidden"
(`/usr/share/omarchy/shell/plugins/bar/Bar.qml:1171`):
```bash
command: ["bash", "-c", "[[ -f $HOME/.local/state/omarchy/toggles/bar-off ]] && echo yes || echo no"]
```
So the flag name already encodes the inverted sense — `bar-off` — and the
generic `on`/`off` actions then apply it the wrong way round:
| Command | `toggles/bar-off` | Bar |
|---|---|---|
| `omarchy toggle bar on` | created | hidden |
| `omarchy toggle bar off` | removed | visible |
## Impact
The documented way to bring the bar back is inverted. A user who runs
`omarchy toggle bar on` to recover a missing bar gets no visible change, and
`omarchy toggle bar` then appears to be a no-op. The desktop looks broken with
no obvious way back except reading `Bar.qml` to find the flag name.
## Notes
`omarchy-toggle` is generic, so it cannot be fixed by swapping `on` and `off`
there — that would invert every other toggle (`idle-lock`, `notifications`,
`crash-capture`, `screensaver`, `nightlight`, `battery-percentage`,
`workspace-layout`, `window-gaps`, `one-window-ratio`). Every other consumer
already treats a present flag as "feature on", so `bar-off` looks like the
odd one out.
Suggested direction, whichever is chosen:
1. Rename the flag to `bar-hidden` and have `omarchy-toggle-bar` map
`on` -> remove, `off` -> create. Keeps `omarchy-toggle` generic.
2. Or keep `bar-off` and translate inside `omarchy-toggle-bar`.
Option 1 also matches the comment already in `Bar.qml:38`.
Migration concern for option 1: an existing `toggles/bar-off` file would be
ignored, so the bar would pop back into view once on upgrade. Probably fine,
but worth a note.
## Environment
- Omarchy 4.0.4-1
- Host `Legend`
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
- Fixed bypr/12155· confirmed
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 20:15 UTC