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-4853GitHub issuePublicReceived

omarchy toggle bar on/off has inverted semantics

Reported by curtisc · filed Sep 3, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #7022 (R-1817). GitHub close reason: completed.

Received and recorded verbatim. Nothing has been checked yet.

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

omarchy toggle bar on/off has inverted semanticsrevision 1 · captured 2026-10-04 12:10 UTC via poll

What happened

omarchy toggle bar on does not show the bar — it hides it. omarchy toggle bar off is what actually makes the bar visible.

Why

omarchy-toggle-bar forwards its on/off argument unchanged to the generic toggle helper against a flag named bar-off:

# /usr/bin/omarchy-toggle-bar
omarchy-toggle bar-off "${1:-toggle}"

The generic omarchy-toggle (/usr/bin/omarchy-toggle) treats on as "create/touch the flag" and off as "remove the flag":

case "$ACTION" in
  ...
  on)
    enable   # touches $HOME/.local/state/omarchy/toggles/$FLAG_NAME
    ;;
  off)
    disable  # rm -f $HOME/.local/state/omarchy/toggles/$FLAG_NAME
    ;;

Since the flag is named bar-off and its presence means the bar is hidden (see Bar.qml's barHiddenProbe, which checks for $HOME/.local/state/omarchy/toggles/bar-off), calling it with on actually creates the bar-off flag — hiding the bar — and off removes it, showing the bar. The words on/off are inverted relative to the visible outcome.

Expected

omarchy toggle bar on shows the bar; omarchy toggle bar off hides it.

Steps to reproduce

  1. omarchy toggle bar off (bar disappears, ~/.local/state/omarchy/toggles/bar-off is created)
  2. omarchy toggle bar on (expect bar to reappear)
  3. Bar stays hidden — the bar-off flag's mtime updates (re-touched) instead of being removed. Layer surface for omarchy-bar keeps its top margin at -barSize, i.e. positioned off-screen.
  4. Running omarchy toggle bar off a second time actually removes the flag and the bar reappears.

Fix suggestion

Invert the action in omarchy-toggle-bar before calling the generic toggle (on -> disable, off -> enable), or rename the underlying flag so its semantics match (bar-shown instead of bar-off).

System details

  • Omarchy version: 4.0.2-1 (channel: stable)
  • Kernel: Linux 7.1.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 21 Aug 2026

Files involved

  • /usr/bin/omarchy-toggle-bar (omarchy-toggle bar-off "${1:-toggle}")
  • /usr/bin/omarchy-toggle (generic enable/disable logic)
  • /usr/share/omarchy/shell/plugins/bar/Bar.qml (barHiddenProbe, checks for presence of toggles/bar-off)

🤖 Generated with Claude Code

https://claude.ai/code/session_01FexQkKz3RHaY2AoyZJaK6s

View raw text
## What happened

`omarchy toggle bar on` does not show the bar — it hides it. `omarchy toggle bar off` is what actually makes the bar visible.

## Why

`omarchy-toggle-bar` forwards its `on`/`off` argument unchanged to the generic toggle helper against a flag named `bar-off`:

```bash
# /usr/bin/omarchy-toggle-bar
omarchy-toggle bar-off "${1:-toggle}"
```

The generic `omarchy-toggle` (`/usr/bin/omarchy-toggle`) treats `on` as "create/touch the flag" and `off` as "remove the flag":

```bash
case "$ACTION" in
  ...
  on)
    enable   # touches $HOME/.local/state/omarchy/toggles/$FLAG_NAME
    ;;
  off)
    disable  # rm -f $HOME/.local/state/omarchy/toggles/$FLAG_NAME
    ;;
```

Since the flag is named `bar-off` and its *presence* means the bar is hidden (see `Bar.qml`'s `barHiddenProbe`, which checks for `$HOME/.local/state/omarchy/toggles/bar-off`), calling it with `on` actually creates the `bar-off` flag — hiding the bar — and `off` removes it, showing the bar. The words `on`/`off` are inverted relative to the visible outcome.

## Expected

`omarchy toggle bar on` shows the bar; `omarchy toggle bar off` hides it.

## Steps to reproduce

1. `omarchy toggle bar off` (bar disappears, `~/.local/state/omarchy/toggles/bar-off` is created)
2. `omarchy toggle bar on` (expect bar to reappear)
3. Bar stays hidden — the `bar-off` flag's mtime updates (re-touched) instead of being removed. Layer surface for `omarchy-bar` keeps its top margin at `-barSize`, i.e. positioned off-screen.
4. Running `omarchy toggle bar off` a second time actually removes the flag and the bar reappears.

## Fix suggestion

Invert the action in `omarchy-toggle-bar` before calling the generic toggle (`on` -> `disable`, `off` -> `enable`), or rename the underlying flag so its semantics match (`bar-shown` instead of `bar-off`).

## System details

- Omarchy version: 4.0.2-1 (channel: stable)
- Kernel: `Linux 7.1.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 21 Aug 2026`

## Files involved

- `/usr/bin/omarchy-toggle-bar` (`omarchy-toggle bar-off "${1:-toggle}"`)
- `/usr/bin/omarchy-toggle` (generic enable/disable logic)
- `/usr/share/omarchy/shell/plugins/bar/Bar.qml` (`barHiddenProbe`, checks for presence of `toggles/bar-off`)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01FexQkKz3RHaY2AoyZJaK6s

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.