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.
Bar clock stays on the pre-suspend minute after resume or lid open
Reported by AndrijaSkontra · filed Oct 4, 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
Lenovo ThinkPad X1 Carbon Gen 8 (20UAS1H108), Intel Core i7-10610U, Intel UHD Graphics (Comet Lake GT2), Omarchy 4.0.0-1, quickshell-git 0.3.0.r20.g28771c7-1. Timezone Europe/Zagreb. timedatectl reports the system clock synchronized with NTP active — the lag is the bar label, not the system clock.
What's wrong?
After suspend, or after closing and opening the lid, the bar clock keeps showing the time from before sleep. It only catches up to the real minute after a delay of up to about 30 seconds (the remainder of the minute timer that was already armed, so the worst case is just under a minute).
Expected: the clock shows the current local time as soon as the session is usable again.
Steps:
- Note the bar clock (default format
dddd HH:mm,omarchy.clock). - Suspend, or close the lid long enough for the minute to change, then resume / open the lid.
- Compare the bar with
date. The bar is still on the pre-suspend minute;dateis already correct. - Wait. The bar jumps forward on its own, without a shell restart, once the timer that was scheduled before sleep fires.
Cause: omarchy.clock displays SystemClock at minute precision and only updates displayDate from onDateChanged:
SystemClock {
id: clock
precision: SystemClock.Minutes
onDateChanged: root.displayDate = date
}plugins/panels/clock/BarWidget.qml. Quickshell's SystemClock::schedule() arms a one-shot QTimer for the delay until the next minute (src/core/clock.cpp). That timer uses CLOCK_MONOTONIC, which does not advance during suspend, so after resume the leftover delay (0–60s) still has to elapse before dateChanged fires. The widget already has refresh() (displayDate = new Date()), but nothing calls it on wake.
Same class of bug the lock screen already guards against: a countdown frozen by suspend fires only after the monotonic remainder elapses (plugins/lock/Service.qml).
Upstream, still open: https://github.com/quickshell-mirror/quickshell/issues/559
A resume hook (logind PrepareForSleep → false, or the existing wake path) that calls the clock refresh() would show the right minute immediately, without waiting on the Quickshell timer.
View raw text
### System details
Lenovo ThinkPad X1 Carbon Gen 8 (20UAS1H108), Intel Core i7-10610U, Intel UHD Graphics (Comet Lake GT2), Omarchy 4.0.0-1, quickshell-git 0.3.0.r20.g28771c7-1. Timezone Europe/Zagreb. `timedatectl` reports the system clock synchronized with NTP active — the lag is the bar label, not the system clock.
### What's wrong?
After suspend, or after closing and opening the lid, the bar clock keeps showing the time from before sleep. It only catches up to the real minute after a delay of up to about 30 seconds (the remainder of the minute timer that was already armed, so the worst case is just under a minute).
**Expected:** the clock shows the current local time as soon as the session is usable again.
**Steps:**
1. Note the bar clock (default format `dddd HH:mm`, `omarchy.clock`).
2. Suspend, or close the lid long enough for the minute to change, then resume / open the lid.
3. Compare the bar with `date`. The bar is still on the pre-suspend minute; `date` is already correct.
4. Wait. The bar jumps forward on its own, without a shell restart, once the timer that was scheduled before sleep fires.
**Cause:** `omarchy.clock` displays `SystemClock` at minute precision and only updates `displayDate` from `onDateChanged`:
```qml
SystemClock {
id: clock
precision: SystemClock.Minutes
onDateChanged: root.displayDate = date
}
```
`plugins/panels/clock/BarWidget.qml`. Quickshell's `SystemClock::schedule()` arms a one-shot `QTimer` for the delay until the next minute (`src/core/clock.cpp`). That timer uses `CLOCK_MONOTONIC`, which does not advance during suspend, so after resume the leftover delay (0–60s) still has to elapse before `dateChanged` fires. The widget already has `refresh()` (`displayDate = new Date()`), but nothing calls it on wake.
Same class of bug the lock screen already guards against: a countdown frozen by suspend fires only after the monotonic remainder elapses (`plugins/lock/Service.qml`).
Upstream, still open: https://github.com/quickshell-mirror/quickshell/issues/559
A resume hook (logind `PrepareForSleep` → false, or the existing wake path) that calls the clock `refresh()` would show the right minute immediately, without waiting on the Quickshell timer.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
- Fixed bypr/12277· confirmed
- Fixed bypr/14264· confirmed
- Fixed bypr/10138· confirmed
- Fixed bypr/13541· confirmed
- Fixed bypr/13347· confirmed
- Fixed bypr/13804· 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 21:21 UTC