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.
Third-party services can no longer observe bar hover and popup state
Reported by D-Gaspa · filed Sep 9, 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
What changed
Omarchy 4.0.3 gives third-party service plugins a restricted bar interface through PluginBarStateApi. It exposes visibility, size, font, and position, but no hover or popup state.
This follows the authentication-boundary changes in #9618 and #10733. Protecting authentication state makes sense; the question is how plugins should now observe ordinary bar interaction without accessing internal objects.
How this affects users
Plugins that coordinate behavior with the bar may still load and appear enabled while silently losing functionality. For example, an autohide service needs to know when the pointer leaves the bar and whether a popup should keep it visible.
Example: Bar Autohide
With Bar Autohide 1.3.0 on Omarchy 4.0.3-1:
- The plugin is enabled and its edge-trigger surface loads.
- Its popup check reads
bar.activePopout, which is no longer exposed. The missing value is interpreted as an open popup, preventing hiding. - Its hover observer relies on access to bar windows, which the restricted interface also removes.
An isolated Quickshell test confirmed the false “popup open” condition. No fixes or downgrade have been tested.
What is the intended integration?
Is there a supported way for third-party services to observe whole-bar hover and whether a bar popup is open?
If not, is this functionality intentionally unavailable, or is a restricted replacement interface planned? Clarifying that would help plugin maintainers adapt without restoring broad access or inventing workarounds.
View raw text
## What changed Omarchy 4.0.3 gives third-party service plugins a restricted bar interface through `PluginBarStateApi`. It exposes visibility, size, font, and position, but no hover or popup state. This follows the authentication-boundary changes in [#9618](https://github.com/omacom/omarchy/pull/9618) and [#10733](https://github.com/omacom/omarchy/pull/10733). Protecting authentication state makes sense; the question is how plugins should now observe ordinary bar interaction without accessing internal objects. ## How this affects users Plugins that coordinate behavior with the bar may still load and appear enabled while silently losing functionality. For example, an autohide service needs to know when the pointer leaves the bar and whether a popup should keep it visible. ### Example: Bar Autohide With [Bar Autohide](https://github.com/ericvrp/omarchy-bar-autohide) 1.3.0 on Omarchy 4.0.3-1: - The plugin is enabled and its edge-trigger surface loads. - Its popup check reads `bar.activePopout`, which is no longer exposed. The missing value is interpreted as an open popup, preventing hiding. - Its hover observer relies on access to bar windows, which the restricted interface also removes. An isolated Quickshell test confirmed the false “popup open” condition. No fixes or downgrade have been tested. ## What is the intended integration? Is there a supported way for third-party services to observe whole-bar hover and whether a bar popup is open? If not, is this functionality intentionally unavailable, or is a restricted replacement interface planned? Clarifying that would help plugin maintainers adapt without restoring broad access or inventing workarounds.
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 11:19 UTC