Proof Portal

Sign in
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-5030GitHub issuePublicFixed

idle.lock: large values overflow the lock Timer's 32-bit interval, causing an infinite 1kHz warning loop and ~1GB/session log growth

Reported by bob-wright8778 · filed Sep 11, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #7506 (R-1654). GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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?
Not yet mapped to any requirement or component.
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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

idle.lock: large values overflow the lock Timer's 32-bit interval, causing an infinite 1kHz warning loop and ~1GB/session log growthrevision 1 · captured 2026-10-04 12:10 UTC via poll

What happened

Setting a large idle.lock value in ~/.config/omarchy/shell.json (intended to
effectively disable auto-lock) causes the idle service's lock Timer to free-run
at 1ms forever for the rest of the shell session, spamming
`WARN: QBasicTimer::start: negative intervals aren't allowed; the interval will
be set to 1ms.` into quickshell's log at ~1kHz. Over a multi-hour session this
writes roughly 1GB per shell instance to
$XDG_RUNTIME_DIR/quickshell/by-id/<id>/log.log. On my machine this filled
/run/user/1000 (a 1.6G tmpfs) to 100%, which then broke unrelated things
(dconf failing to allocate its user file, omarchy-restart-shell failing its
readiness check).

Root cause

plugins/services/idle/Service.qml:

Timer {
  id: lockTimer
  interval: root.lockDelaySeconds * 1000
}

lockDelaySeconds comes from the configured idle.lock seconds value via
IdleModel.secondsFromConfig, which only rejects negative/non-finite input —
it has no upper bound:

function secondsFromConfig(value, fallback) {
  var n = Number(value)
  if (!isFinite(n) || n < 0) return fallback
  return Math.floor(n)
}

QML Timer.interval is a 32-bit signed int in milliseconds (max ≈ 2147483647ms
≈ 24.8 days). With idle.lock: 999999999, lockDelaySeconds * 1000 =
999999849000, which overflows that range and wraps to a negative number.
QBasicTimer::start rejects the negative interval and clamps to 1ms, the timer
fires again 1ms later, recomputes the same overflowed negative interval, and the
cycle repeats indefinitely — for the rest of the shell session.

Steps to reproduce

  1. Set "idle": {"screensaver": 150, "lock": 999999999} in

~/.config/omarchy/shell.json.
2. omarchy-restart-shell, then wait for an idle cycle to start (the log line
idle-cycle-start: screensaver=150 lock=999999999 marks it).
3. Watch $XDG_RUNTIME_DIR/quickshell/by-id/<id>/log.log grow rapidly, filled
with the QBasicTimer::start: negative intervals warning at roughly 1kHz.

Suggested fix

Clamp/validate idle.lock (and idle.screensaver) in
IdleModel.secondsFromConfig to a safe maximum well under the 32-bit ms
overflow point (e.g. ~2,000,000 seconds), or add a proper "disabled" sentinel
for auto-lock so users don't have to guess a large-but-safe number to mean
"never".

System

  • Omarchy 4.0.2-1, stable channel
  • Quickshell 0.3.1-1 (Arch)

Filed by Claude Sonnet 5 via Claude Code.

View raw text
## What happened
Setting a large `idle.lock` value in `~/.config/omarchy/shell.json` (intended to
effectively disable auto-lock) causes the idle service's lock `Timer` to free-run
at 1ms forever for the rest of the shell session, spamming
`WARN: QBasicTimer::start: negative intervals aren't allowed; the interval will
be set to 1ms.` into quickshell's log at ~1kHz. Over a multi-hour session this
writes roughly 1GB per shell instance to
`$XDG_RUNTIME_DIR/quickshell/by-id/<id>/log.log`. On my machine this filled
`/run/user/1000` (a 1.6G tmpfs) to 100%, which then broke unrelated things
(dconf failing to allocate its user file, `omarchy-restart-shell` failing its
readiness check).

## Root cause
`plugins/services/idle/Service.qml`:
```qml
Timer {
  id: lockTimer
  interval: root.lockDelaySeconds * 1000
}
```
`lockDelaySeconds` comes from the configured `idle.lock` seconds value via
`IdleModel.secondsFromConfig`, which only rejects negative/non-finite input —
it has no upper bound:
```js
function secondsFromConfig(value, fallback) {
  var n = Number(value)
  if (!isFinite(n) || n < 0) return fallback
  return Math.floor(n)
}
```
QML `Timer.interval` is a 32-bit signed int in milliseconds (max ≈ 2147483647ms
≈ 24.8 days). With `idle.lock: 999999999`, `lockDelaySeconds * 1000` =
`999999849000`, which overflows that range and wraps to a negative number.
`QBasicTimer::start` rejects the negative interval and clamps to 1ms, the timer
fires again 1ms later, recomputes the same overflowed negative interval, and the
cycle repeats indefinitely — for the rest of the shell session.

## Steps to reproduce
1. Set `"idle": {"screensaver": 150, "lock": 999999999}` in
   `~/.config/omarchy/shell.json`.
2. `omarchy-restart-shell`, then wait for an idle cycle to start (the log line
   `idle-cycle-start: screensaver=150 lock=999999999` marks it).
3. Watch `$XDG_RUNTIME_DIR/quickshell/by-id/<id>/log.log` grow rapidly, filled
   with the `QBasicTimer::start: negative intervals` warning at roughly 1kHz.

## Suggested fix
Clamp/validate `idle.lock` (and `idle.screensaver`) in
`IdleModel.secondsFromConfig` to a safe maximum well under the 32-bit ms
overflow point (e.g. ~2,000,000 seconds), or add a proper "disabled" sentinel
for auto-lock so users don't have to guess a large-but-safe number to mean
"never".

## System
- Omarchy 4.0.2-1, stable channel
- Quickshell 0.3.1-1 (Arch)

Filed by Claude Sonnet 5 via Claude Code.

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/9170· 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.

No decision has been recorded yet.