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.
Idle timeouts above ~24.8 days overflow the Qt timer and flood the shell log until /run/user fills up
Reported by Coding-Sparrow · filed Oct 1, 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
Intel Core Ultra 9 185H, Intel Arc Graphics (Meteor Lake), Omarchy 4.0.4-1
What's wrong?
If idle.lock or idle.screensaver in ~/.config/omarchy/shell.json is larger than about 24.8 days, the shell writes a warning to its log every millisecond while idle. The log is stored in tmpfs, so after a few hours it fills /run/user/$UID. Then anything else that writes there breaks too: in my case two shell plugins started failing with ENOSPC.
A very large value is a natural way to say "never lock", and nothing in the manual mentions an upper limit.
Steps to reproduce
- Set the following in
~/.config/omarchy/shell.json:
"idle": { "screensaver": 150, "lock": 999999999 }- Stay idle past the screensaver timeout.
- Watch
/run/user/$UID/quickshell/by-id/*/log.log.
What happens
DEBUG qml: omarchy idle ... idle-cycle-start: screensaver=150 lock=999999999
WARN: QBasicTimer::start: negative intervals aren't allowed; the interval will be set to 1ms.
WARN: QBasicTimer::start: negative intervals aren't allowed; the interval will be set to 1ms.
... (about 1000 lines per second)After about 13 hours the log was 3.1 GB, and /run/user/1000 (3.1 GB tmpfs) was 100% full.
Expected
The lock timer either effectively never fires, or the value is capped. It should not overflow.
Cause
shell/plugins/services/idle/IdleModel.js secondsFromConfig() sets no upper limit. Service.qml then computes interval: root.lockDelaySeconds * 1000. Qt Timer.interval is a signed 32-bit int in milliseconds, so anything above 2147483 seconds wraps to a negative number, and Qt clamps that to 1 ms.
Fix
PR to follow: cap secondsFromConfig at floor(INT32_MAX / 1000) seconds.
Workaround
Use "lock": 2000000 (about 23 days), or toggle stay-awake with omarchy toggle idle.
View raw text
### System details
Intel Core Ultra 9 185H, Intel Arc Graphics (Meteor Lake), Omarchy 4.0.4-1
### What's wrong?
If `idle.lock` or `idle.screensaver` in `~/.config/omarchy/shell.json` is larger than about 24.8 days, the shell writes a warning to its log every millisecond while idle. The log is stored in tmpfs, so after a few hours it fills `/run/user/$UID`. Then anything else that writes there breaks too: in my case two shell plugins started failing with `ENOSPC`.
A very large value is a natural way to say "never lock", and nothing in the manual mentions an upper limit.
**Steps to reproduce**
1. Set the following in `~/.config/omarchy/shell.json`:
```json
"idle": { "screensaver": 150, "lock": 999999999 }
```
2. Stay idle past the screensaver timeout.
3. Watch `/run/user/$UID/quickshell/by-id/*/log.log`.
**What happens**
```
DEBUG qml: omarchy idle ... idle-cycle-start: screensaver=150 lock=999999999
WARN: QBasicTimer::start: negative intervals aren't allowed; the interval will be set to 1ms.
WARN: QBasicTimer::start: negative intervals aren't allowed; the interval will be set to 1ms.
... (about 1000 lines per second)
```
After about 13 hours the log was 3.1 GB, and `/run/user/1000` (3.1 GB tmpfs) was 100% full.
**Expected**
The lock timer either effectively never fires, or the value is capped. It should not overflow.
**Cause**
`shell/plugins/services/idle/IdleModel.js` `secondsFromConfig()` sets no upper limit. `Service.qml` then computes `interval: root.lockDelaySeconds * 1000`. Qt `Timer.interval` is a signed 32-bit int in milliseconds, so anything above 2147483 seconds wraps to a negative number, and Qt clamps that to 1 ms.
**Fix**
PR to follow: cap `secondsFromConfig` at `floor(INT32_MAX / 1000)` seconds.
**Workaround**
Use `"lock": 2000000` (about 23 days), or toggle stay-awake with `omarchy toggle idle`.
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.
- Out of scopeDecided by agents · verified · 2026-10-09 02:19 UTC