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.
System-update icon only appears on one monitor (checkupdates race)
Reported by loraque-git · filed Sep 16, 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 happened
With two bars (one per monitor), the Omarchy update indicator (omarchy.system-update) only lights up on one screen. Clock, workspaces, tray, etc. show on both.
Why
SystemUpdate.qml starts omarchy-update-available from a Timer { triggeredOnStart: true } on every bar instance at once. That script calls checkupdates. Pacman only allows one of those to succeed.
The loser exits non-zero and this line hides the icon on that monitor:
onExited: function(exitCode) {
root.updateAvailable = exitCode === 0
}Reproduced on 4.0.3 and 4.0.4: consecutive runs of omarchy-update-available flip between “up to date” (exit 1) and a real omarchy x -> y line (exit 0).
BarWidget.broadcast() already exists because IPC only hits one handler. The timer path does not use it, and even a broadcast of refresh() would re-run the same racy check. A success on any instance needs to set updateAvailable on all peers, and a failure must not clear a peer that already succeeded.
Repro
- Two monitors, stock bar,
omarchy.system-updatein the layout. - Have a pending
omarchypackage update. - Restart the shell (
omarchy restart shell) so both timers fire together. - The circular-arrow icon appears on one bar only.
Expected
Same as the other bar widgets: the icon on every monitor, or a documented single-bar-only widget.
Environment
- Omarchy 4.0.4-1
- Two 1920×1080 outputs (HDMI-A-1, DP-1)
- Hyprland / omarchy-shell
Workaround
A cloned widget that, on exit 0, sets updateAvailable = true on every moduleWidgets(...) instance and ignores a later exit 1 if already true.
View raw text
## What happened
With two bars (one per monitor), the Omarchy update indicator (`omarchy.system-update`) only lights up on **one** screen. Clock, workspaces, tray, etc. show on both.
## Why
`SystemUpdate.qml` starts `omarchy-update-available` from a `Timer { triggeredOnStart: true }` on **every** bar instance at once. That script calls `checkupdates`. Pacman only allows one of those to succeed.
The loser exits non-zero and this line hides the icon on that monitor:
```qml
onExited: function(exitCode) {
root.updateAvailable = exitCode === 0
}
```
Reproduced on 4.0.3 and 4.0.4: consecutive runs of `omarchy-update-available` flip between “up to date” (exit 1) and a real `omarchy x -> y` line (exit 0).
`BarWidget.broadcast()` already exists because IPC only hits one handler. The timer path does not use it, and even a broadcast of `refresh()` would re-run the same racy check. A success on any instance needs to set `updateAvailable` on **all** peers, and a failure must not clear a peer that already succeeded.
## Repro
1. Two monitors, stock bar, `omarchy.system-update` in the layout.
2. Have a pending `omarchy` package update.
3. Restart the shell (`omarchy restart shell`) so both timers fire together.
4. The circular-arrow icon appears on one bar only.
## Expected
Same as the other bar widgets: the icon on **every** monitor, or a documented single-bar-only widget.
## Environment
- Omarchy 4.0.4-1
- Two 1920×1080 outputs (HDMI-A-1, DP-1)
- Hyprland / omarchy-shell
## Workaround
A cloned widget that, on exit 0, sets `updateAvailable = true` on every `moduleWidgets(...)` instance and ignores a later exit 1 if already true.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 14:31 UTC