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: on/off arguments are inverted
Reported by Vairo0-0 · filed Sep 27, 2026 · open at source
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 hides the bar, and omarchy toggle bar off shows it. Theon and off arguments are inverted.
bin/omarchy-toggle-bar forwards its argument straight to the bar-off flag:
omarchy-toggle bar-off "${1:-toggle}"But the flag name and the user-facing argument name have opposite polarity. Inshell/plugins/bar/Bar.qml the flag is read as an inversion:
command: ["bash", "-c", "[[ -f $HOME/.local/state/omarchy/toggles/bar-off ]] && echo yes || echo no"]
stdout: SplitParser { onRead: function(line) { root.barHidden = String(line).trim() === "yes" } }So the flag being present means the bar is hidden. Passing on toomarchy-toggle bar-off creates the flag, which hides the bar.
Steps to reproduce
- Bar visible,
~/.local/state/omarchy/toggles/bar-offabsent. - Run
omarchy toggle bar on. - The bar disappears, and
~/.local/state/omarchy/toggles/bar-offnow exists. - Run
omarchy toggle bar off. - The bar reappears and the flag is removed.
The same inversion applies to a bare omarchy toggle bar, which just flips the
flag — it happens to work, which is probably why this has gone unnoticed.
Expected
omarchy toggle bar on→ bar shown, nobar-offflagomarchy toggle bar off→ bar hidden,bar-offflag present
Suggested fix
Invert the action before handing it to the flag:
case "${1:-toggle}" in
on) action=off ;;
off) action=on ;;
*) action="${1:-toggle}" ;;
esac
omarchy-toggle bar-off "$action"Impact
The failure mode is confusing rather than obvious. hyprctl layers still shows
the omarchy-bar layer, so the shell looks healthy, but the surface is parked
one bar-height past the screen edge:
$ hyprctl layers | grep omarchy-bar
Layer 5b5c98c33ad0: xywh: 0 768 1366 26, a: 1, namespace: omarchy-bary=768 on a 768px-tall monitor means the bar is entirely off screen, and
nothing on the display indicates why. Diagnosing it requires knowing that the
bar has a park-off-screen hidden state and that ~/.local/state/omarchy/toggles/
controls it.
I hit this when trying to restore a bar I had hidden with the same command
group, which is the most likely thing anyone does with it.
System
- Omarchy: 4.0.4-1
- Kernel: 7.2.5-3-omarchy x86_64
- GPU: NVIDIA GeForce GTX 1050 Ti
- Reproducible on a single machine; no evidence it is hardware specific, since
the inversion is entirely in argument handling
View raw text
## Summary
`omarchy toggle bar on` hides the bar, and `omarchy toggle bar off` shows it. The
`on` and `off` arguments are inverted.
`bin/omarchy-toggle-bar` forwards its argument straight to the `bar-off` flag:
```bash
omarchy-toggle bar-off "${1:-toggle}"
```
But the flag name and the user-facing argument name have opposite polarity. In
`shell/plugins/bar/Bar.qml` the flag is read as an inversion:
```qml
command: ["bash", "-c", "[[ -f $HOME/.local/state/omarchy/toggles/bar-off ]] && echo yes || echo no"]
stdout: SplitParser { onRead: function(line) { root.barHidden = String(line).trim() === "yes" } }
```
So the flag being *present* means the bar is *hidden*. Passing `on` to
`omarchy-toggle bar-off` creates the flag, which hides the bar.
## Steps to reproduce
1. Bar visible, `~/.local/state/omarchy/toggles/bar-off` absent.
2. Run `omarchy toggle bar on`.
3. The bar disappears, and `~/.local/state/omarchy/toggles/bar-off` now exists.
4. Run `omarchy toggle bar off`.
5. The bar reappears and the flag is removed.
The same inversion applies to a bare `omarchy toggle bar`, which just flips the
flag — it happens to work, which is probably why this has gone unnoticed.
## Expected
- `omarchy toggle bar on` → bar shown, no `bar-off` flag
- `omarchy toggle bar off` → bar hidden, `bar-off` flag present
## Suggested fix
Invert the action before handing it to the flag:
```bash
case "${1:-toggle}" in
on) action=off ;;
off) action=on ;;
*) action="${1:-toggle}" ;;
esac
omarchy-toggle bar-off "$action"
```
## Impact
The failure mode is confusing rather than obvious. `hyprctl layers` still shows
the `omarchy-bar` layer, so the shell looks healthy, but the surface is parked
one bar-height past the screen edge:
```
$ hyprctl layers | grep omarchy-bar
Layer 5b5c98c33ad0: xywh: 0 768 1366 26, a: 1, namespace: omarchy-bar
```
`y=768` on a 768px-tall monitor means the bar is entirely off screen, and
nothing on the display indicates why. Diagnosing it requires knowing that the
bar has a park-off-screen hidden state and that `~/.local/state/omarchy/toggles/`
controls it.
I hit this when trying to restore a bar I had hidden with the same command
group, which is the most likely thing anyone does with it.
## System
- Omarchy: 4.0.4-1
- Kernel: 7.2.5-3-omarchy x86_64
- GPU: NVIDIA GeForce GTX 1050 Ti
- Reproducible on a single machine; no evidence it is hardware specific, since
the inversion is entirely in argument handling
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 19:41 UTC