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.
Trusted path for service-backed widgets on replacement bars (follow-up to #9618)
Reported by felixzsh · filed Sep 13, 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
Follow-up to #9618 (which intentionally removed the generic facade factory from
replacement bars).
Impact: a third-party kind: bar plugin can only give the widgets it hosts a
service-less facade, so bar.shell.serviceFor("<id>") returns null. Service-backed
widgets then render empty on the bar while their panels still work. This hits
replacement bars that render the same registered widgets as the built-in bar — for
example my plugin felixzsh.widget-islands,
where widgets such as YouTube Music, media and live counters are blank on the bar.
Cause: pluginShellForBarEntry() in shell/shell.qml has no _serviceLookup, and a
third-party bar's shell does not expose pluginShellForId, so Bar.qml'spluginBarApiFor() always falls back to that service-less entry facade.
Introduced by #9618:
- 1702cf0b Restrict third-party shell plugin capabilities
- 094c9130 Tighten replacement bar plugin boundaries
- 572a34d3 Refresh cached plugin bar shell facades
Question: is a trusted/validated path planned for this — e.g. a per-widget service
facade scoped to the widget's own service, or a way to mark widgets/replacement bars
as trusted — so replacement bars like mine can host service-backed widgets? If not,
what is the recommended pattern for a replacement bar that must render the same
widgets as the built-in bar?
View raw text
Follow-up to #9618 (which intentionally removed the generic facade factory from
replacement bars).
Impact: a third-party `kind: bar` plugin can only give the widgets it hosts a
service-less facade, so `bar.shell.serviceFor("<id>")` returns null. Service-backed
widgets then render empty on the bar while their panels still work. This hits
replacement bars that render the same registered widgets as the built-in bar — for
example my plugin [felixzsh.widget-islands](https://github.com/felixzsh/omarchy-widget-islands),
where widgets such as YouTube Music, media and live counters are blank on the bar.
Cause: `pluginShellForBarEntry()` in `shell/shell.qml` has no `_serviceLookup`, and a
third-party bar's `shell` does not expose `pluginShellForId`, so `Bar.qml`'s
`pluginBarApiFor()` always falls back to that service-less entry facade.
Introduced by #9618:
- 1702cf0b Restrict third-party shell plugin capabilities
- 094c9130 Tighten replacement bar plugin boundaries
- 572a34d3 Refresh cached plugin bar shell facades
Question: is a trusted/validated path planned for this — e.g. a per-widget service
facade scoped to the widget's own service, or a way to mark widgets/replacement bars
as trusted — so replacement bars like mine can host service-backed widgets? If not,
what is the recommended pattern for a replacement bar that must render the same
widgets as the built-in bar?
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 12:51 UTC