Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-5140GitHub issuePublicFixed

Bar clock stays on the pre-suspend minute after resume or lid open

Reported by AndrijaSkontra · filed Oct 4, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 days ago.

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

Bar clock stays on the pre-suspend minute after resume or lid openrevision 1 · captured 2026-10-04 15:28 UTC via poll

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:

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