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.
Bar: the centre-section reveal is shell-wide, so one monitor's bar drives every monitor's peek
Reported by jrmmhm · filed Aug 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
shell/plugins/bar/Bar.qml keeps barHoverCount as one integer on the bar root.
Every surface's HoverHandler reports into it through setBarHovered, andbarHovered is barHoverCount > 0.
The counter itself is right, and its comment says why: a pointer crossing from
one monitor's bar to another's has to stay counted however the enter and leave
interleave, and a shared bool would be left false by whichever event landed
last. What was never decided is that the state derived from it should be
shell-wide too.
centerSectionRevealHeld is likewise a single root property, set fromsetCenterSectionHovered and cleared by centerSectionRevealTimer only when!centerSectionHovered && !barHovered. widgets/Indicators.qml bindsrevealInactiveIndicators to it. So one monitor's centre-section hover reveals
the inactive indicators on every monitor, and any monitor's bar hover holds that
reveal open.
Reproduction, without any third-party plugin
On two or more monitors, with the bar's indicators widget in the centre section:
- Put the pointer on one monitor's centre section.
- Look at the other monitors.
The inactive indicators appear on all of them. Move the pointer to a different
monitor's bar, away from its centre section: they stay. They collapse only once
the pointer has left every bar.
Observable without looking, through the shell's own IPC:
omarchy-shell shell debugBarGeometry | jq '.[] | select(.id=="omarchy.indicators") | {x, width}'Measured
Environment as in the sibling report. Three outputs.
With the pointer resting on one monitor's centre section, debugBarGeometry
reported omarchy.indicators at 126 px on all three outputs, against
21 px with the pointer off every bar.
Separately, three per-screen layer surfaces running setBarHovered,barHoverCount and barHovered verbatim: with the pointer on one surface only,
the shell-wide flag read barHovered=true while the other two surfaces both
reported not hovered.
What a fix has to keep
Narrowing the guard to "the pointer is on one of my slots" does not work. The
hover handler deliberately fills the whole bar surface including the empty runs
between the sections, a hidden slot is zero-width and cannot be hovered at all,
and the guard exists precisely to hold the reveal while the pointer rests
somewhere that collapsing would move something under it. The counter can stay
one counter; what needs to become per-surface is the reveal state it feeds.
View raw text
`shell/plugins/bar/Bar.qml` keeps `barHoverCount` as one integer on the bar root.
Every surface's `HoverHandler` reports into it through `setBarHovered`, and
`barHovered` is `barHoverCount > 0`.
The counter itself is right, and its comment says why: a pointer crossing from
one monitor's bar to another's has to stay counted however the enter and leave
interleave, and a shared bool would be left false by whichever event landed
last. What was never decided is that the state *derived* from it should be
shell-wide too.
`centerSectionRevealHeld` is likewise a single root property, set from
`setCenterSectionHovered` and cleared by `centerSectionRevealTimer` only when
`!centerSectionHovered && !barHovered`. `widgets/Indicators.qml` binds
`revealInactiveIndicators` to it. So one monitor's centre-section hover reveals
the inactive indicators on every monitor, and any monitor's bar hover holds that
reveal open.
### Reproduction, without any third-party plugin
On two or more monitors, with the bar's indicators widget in the centre section:
1. Put the pointer on **one** monitor's centre section.
2. Look at the other monitors.
The inactive indicators appear on all of them. Move the pointer to a different
monitor's bar, away from its centre section: they stay. They collapse only once
the pointer has left every bar.
Observable without looking, through the shell's own IPC:
```
omarchy-shell shell debugBarGeometry | jq '.[] | select(.id=="omarchy.indicators") | {x, width}'
```
### Measured
Environment as in the sibling report. Three outputs.
With the pointer resting on one monitor's centre section, `debugBarGeometry`
reported `omarchy.indicators` at **126 px on all three** outputs, against
**21 px** with the pointer off every bar.
Separately, three per-screen layer surfaces running `setBarHovered`,
`barHoverCount` and `barHovered` verbatim: with the pointer on one surface only,
the shell-wide flag read `barHovered=true` while the other two surfaces both
reported not hovered.
### What a fix has to keep
Narrowing the guard to "the pointer is on one of *my* slots" does not work. The
hover handler deliberately fills the whole bar surface including the empty runs
between the sections, a hidden slot is zero-width and cannot be hovered at all,
and the guard exists precisely to hold the reveal while the pointer rests
somewhere that collapsing would move something under it. The counter can stay
one counter; what needs to become per-surface is the reveal state it feeds.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 09:38 UTC