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.
Feature: Make omarchy.indicators extensible for third-party indicators
Reported by burninc0de · filed Aug 25, 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
Allow third-party plugins to contribute indicators to the existing omarchy.indicators hover-reveal group (Dnd, NightLight, StayAwake, Dictation, ScreenRecording, Reminder) without monkey-patching the cloned plugin.
Current situation
To add a custom indicator that sits politely with the built-ins (same center hover-reveal, same BarIndicator styling), a plugin has to:
omarchy plugin clone omarchy.indicators→burninc0de.indicatorscp CleanKbd.qml burninc0de.indicators/indicators/CleanKbd.qmlsed -i 's/"StayAwake" ]/"StayAwake", "CleanKbd" ]/' Indicators.qml- Patch
manifest.jsonbarWidget.schema[0].options
Example: JoeJoeflyn/omaclean does exactly this. It has to declare kinds: ["service"] and inject a BarIndicator into another plugin's directory.
This works, but it's fragile:
- Any rm -rf burninc0de.indicators or omarchy plugin clone omarchy.indicators wipes the patch (reverts Indicators.qml + manifest.json)
- The fork diverges from upstream and needs manual re-patching after updates
- Two plugins doing the same thing would clobber each other
omarchy theme set is safe (only touches current/theme), but any plugin operation that touches the indicators clone is not.
I don't want a standalone bar-widget — that would be a separate bar block, not part of the grouped indicator UX. The grouping is the feature.
Proposal
Add a first-class extension point, e.g.:
- New kind
indicator(orkinds: ["indicator"]/provides: indicator):
{
"id": "omaclean",
"kinds": ["service", "indicator"],
"entryPoints": { "service": "Service.qml", "indicator": "CleanKbd.qml" },
"indicator": { "id": "CleanKbd", "label": "Clean keyboard", "description": "Lock keyboard for cleaning" }
}omarchy.indicators(Indicators.qml/PluginRegistry.qml) scansinstalledPluginsfor that kind and dynamically adds them todefaultIndicatorEntriesand themanifest.optionslist, loading the QML viaQt.resolvedUrl(pluginDir + "/CleanKbd.qml")instead of only"indicators/" + id + ".qml".
No file copies, no sed, no fork to maintain. An omaclean-type plugin could ship Service.qml + CleanKbd.qml and just appear in the center cluster with NightLight/StayAwake.
Happy to help test or draft a PR if this direction sounds right.
View raw text
### Summary
Allow third-party plugins to contribute indicators to the existing `omarchy.indicators` hover-reveal group (`Dnd`, `NightLight`, `StayAwake`, `Dictation`, `ScreenRecording`, `Reminder`) without monkey-patching the cloned plugin.
### Current situation
To add a custom indicator that *sits politely* with the built-ins (same center hover-reveal, same `BarIndicator` styling), a plugin has to:
1. `omarchy plugin clone omarchy.indicators` → `burninc0de.indicators`
2. `cp CleanKbd.qml burninc0de.indicators/indicators/CleanKbd.qml`
3. `sed -i 's/"StayAwake" ]/"StayAwake", "CleanKbd" ]/' Indicators.qml`
4. Patch `manifest.json` `barWidget.schema[0].options`
Example: [JoeJoeflyn/omaclean](https://github.com/JoeJoeflyn/omaclean) does exactly this. It has to declare `kinds: ["service"]` and inject a `BarIndicator` into another plugin's directory.
This works, but it's fragile:
- Any `rm -rf burninc0de.indicators` or `omarchy plugin clone omarchy.indicators` wipes the patch (reverts `Indicators.qml` + `manifest.json`)
- The fork diverges from upstream and needs manual re-patching after updates
- Two plugins doing the same thing would clobber each other
`omarchy theme set` is safe (only touches `current/theme`), but any plugin operation that touches the indicators clone is not.
I don't want a standalone `bar-widget` — that would be a separate bar block, not part of the grouped indicator UX. The grouping *is* the feature.
### Proposal
Add a first-class extension point, e.g.:
* New kind `indicator` (or `kinds: ["indicator"]` / `provides: indicator`):
```json
{
"id": "omaclean",
"kinds": ["service", "indicator"],
"entryPoints": { "service": "Service.qml", "indicator": "CleanKbd.qml" },
"indicator": { "id": "CleanKbd", "label": "Clean keyboard", "description": "Lock keyboard for cleaning" }
}
```
* `omarchy.indicators` (`Indicators.qml` / `PluginRegistry.qml`) scans `installedPlugins` for that kind and dynamically adds them to `defaultIndicatorEntries` and the `manifest.options` list, loading the QML via `Qt.resolvedUrl(pluginDir + "/CleanKbd.qml")` instead of only `"indicators/" + id + ".qml"`.
No file copies, no `sed`, no fork to maintain. An `omaclean`-type plugin could ship `Service.qml` + `CleanKbd.qml` and just appear in the center cluster with `NightLight`/`StayAwake`.
Happy to help test or draft a PR if this direction sounds right.
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 08:43 UTC