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.
Power panel spawns three helper processes every five seconds while open
Reported by evo-social-world · filed Aug 20, 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
System details
MSI Prestige 16 Flip AI+ C3MTG laptop; Intel Core Ultra X7 358H; Intel Panther Lake Arc B390; Omarchy 4.0.0-1; Hyprland 0.56.2; Quickshell 0.3.0.r20.g28771c7.
What's wrong?
The Quattro power panel starts three external processes every five seconds for as long as the detail panel remains open:
omarchy-battery-status --shellomarchy-powerprofiles-list --active-stateomarchy-system-stats
refresh() starts all three processes, and the repeating timer calls it with interval: 5000:
https://github.com/basecamp/omarchy/blob/quattro/shell/plugins/panels/power/Panel.qml#L135-L150
https://github.com/basecamp/omarchy/blob/quattro/shell/plugins/panels/power/Panel.qml#L208-L231
That is 12 refreshes/minute × 3 commands = approximately 36 process launches per minute while the panel is open. This is unnecessarily aggressive for battery-powered laptops.
systemInfo is assigned from omarchy-system-stats, but it is never read anywhere else in Panel.qml, so one third of those process launches currently produces unused data.
Steps to reproduce
- Use the stock
omarchy.powerwidget on Quattro. - Open the power detail panel.
- Leave it open for one minute.
- Observe that all three
Processobjects are started every five seconds, as specified by the timer andrefresh()implementation above.
Expected behavior
The closed bar should remain reactive through UPower without helper polling. While the detail panel is open:
- Battery telemetry can use a laptop-friendly interval such as 30 seconds.
- Power profiles should refresh when the panel opens and immediately after changing a profile; they do not need a five-second poll.
omarchy-system-statsshould not run unless its data is actually displayed.
Validated local change
I tested a user-owned clone with:
- Battery refresh every 30 seconds while the panel is open.
- Profile refresh only on open and after a profile action.
- The unused system-stat process removed.
- No helper polling while the panel is closed.
The actual panel still rendered battery state, rate, remaining time, and profile controls correctly. The battery helper state updated at 15:16:30.286 and 15:17:00.328 (30.04 seconds apart). After closing the panel, the state timestamp remained unchanged for a further 32 seconds. No power-widget QML errors were logged.
This reduces steady-state external command launches from approximately 36/minute to 2/minute while open, and zero while closed.
View raw text
### System details MSI Prestige 16 Flip AI+ C3MTG laptop; Intel Core Ultra X7 358H; Intel Panther Lake Arc B390; Omarchy 4.0.0-1; Hyprland 0.56.2; Quickshell 0.3.0.r20.g28771c7. ### What's wrong? The Quattro power panel starts three external processes every five seconds for as long as the detail panel remains open: - `omarchy-battery-status --shell` - `omarchy-powerprofiles-list --active-state` - `omarchy-system-stats` `refresh()` starts all three processes, and the repeating timer calls it with `interval: 5000`: https://github.com/basecamp/omarchy/blob/quattro/shell/plugins/panels/power/Panel.qml#L135-L150 https://github.com/basecamp/omarchy/blob/quattro/shell/plugins/panels/power/Panel.qml#L208-L231 That is 12 refreshes/minute × 3 commands = approximately 36 process launches per minute while the panel is open. This is unnecessarily aggressive for battery-powered laptops. `systemInfo` is assigned from `omarchy-system-stats`, but it is never read anywhere else in `Panel.qml`, so one third of those process launches currently produces unused data. ### Steps to reproduce 1. Use the stock `omarchy.power` widget on Quattro. 2. Open the power detail panel. 3. Leave it open for one minute. 4. Observe that all three `Process` objects are started every five seconds, as specified by the timer and `refresh()` implementation above. ### Expected behavior The closed bar should remain reactive through UPower without helper polling. While the detail panel is open: - Battery telemetry can use a laptop-friendly interval such as 30 seconds. - Power profiles should refresh when the panel opens and immediately after changing a profile; they do not need a five-second poll. - `omarchy-system-stats` should not run unless its data is actually displayed. ### Validated local change I tested a user-owned clone with: - Battery refresh every 30 seconds while the panel is open. - Profile refresh only on open and after a profile action. - The unused system-stat process removed. - No helper polling while the panel is closed. The actual panel still rendered battery state, rate, remaining time, and profile controls correctly. The battery helper state updated at `15:16:30.286` and `15:17:00.328` (30.04 seconds apart). After closing the panel, the state timestamp remained unchanged for a further 32 seconds. No power-widget QML errors were logged. This reduces steady-state external command launches from approximately 36/minute to 2/minute while open, and zero while closed.
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
- Related PRpr/9435· confirmed
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 04:52 UTC