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.
Stale sessionLock.locked wedges all future locks (sibling of #6888)
Reported by dsundt · filed Oct 10, 2026 · open at source
R-5240 is the earliest report of this defect — filed Oct 8, 2026, open upstream. This report (filed Oct 10, 2026) describes the same defect, so it is folded under it in the inbox.
Decided by agents · verified· Oct 10, 2026
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?
- 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
Stale sessionLock.locked wedges all future locks (sibling of #6888)
#6888 covers recovery stalling on stale sessionLock.secure. This is the
mirror image: the model holds stale `sessionLock.locked=true` while the
compositor holds nothing, and every new lock no-ops the same way.
Observed state (omarchy-shell lock status)
{"locked":true,"requested":false,"pending":false,"sessionLocked":false,
"secure":false,"realScreens":1,"passwordPam":true,"fingerprint":false,
"fingerprintUnavailable":false,"authenticating":false,
"lastEvent":"unlocked","lastEventAt":"<15+ min stale>"}At the same time, all of these agree nothing is locked:
omarchy-hyprland-session-lockedexits 1hyprctl monitors -j:solitaryBlockedByisWINDOWED/CANDIDATE, noLOCKhyprctl layers: onlyomarchy-background+omarchy-bar, no lock layer- desktop fully usable; single quickshell instance, no crash, no coredump
SUPER+CTRL+L and omarchy-shell lock lock both answer ok and nothing
happens. Only omarchy restart shell clears it (fresh instance reportslocked:false).
Mechanism
requestSessionLock() early-returns on sessionLock.locked || sessionLock.secure
— the same L64 guard as #6888. Here it is a stale locked, left behind by a
previous successful lock→unlock cycle (observed twice: the next lock after any
completed unlock cycle no-ops; intermittently otherwise). The WlSessionLock
model object keeps locked=true after the compositor has released, so the
shell concludes a lock is in place and declines to create one. Nothing retries
and nothing logs it — the failure is completely silent.
Suggested fix
Same family as #6888's: the shell needs to reconcile the model with the
compositor instead of trusting it — e.g. treat locked && !sessionLocked
with no request in flight as desync (re-read/probe rather than early-return),
and/or bound the spin with a loud failure. Happy to test a build.
Environment
- omarchy 4.0.0.alpha, quickshell 0.3.2 (omarchy-distributed), Hyprland 0.56.2
- ThinkPad P16s Gen 4 AMD, single external display (clamshell, docked), realScreens:1
- Local mitigation in use: a 30 s user timer watches for
locked && !sessionLocked && !requested && !authenticating persisting ~90 s
and restarts the shell (proven reset, zero false positives by construction:
idle shows locked:false, every engaged lock shows requested/authenticating/sessionLocked).
View raw text
## Stale `sessionLock.locked` wedges all future locks (sibling of #6888)
#6888 covers recovery stalling on stale `sessionLock.secure`. This is the
mirror image: the model holds stale **`sessionLock.locked=true`** while the
compositor holds nothing, and every new lock no-ops the same way.
### Observed state (`omarchy-shell lock status`)
```json
{"locked":true,"requested":false,"pending":false,"sessionLocked":false,
"secure":false,"realScreens":1,"passwordPam":true,"fingerprint":false,
"fingerprintUnavailable":false,"authenticating":false,
"lastEvent":"unlocked","lastEventAt":"<15+ min stale>"}
```
At the same time, all of these agree nothing is locked:
- `omarchy-hyprland-session-locked` exits 1
- `hyprctl monitors -j`: `solitaryBlockedBy` is `WINDOWED`/`CANDIDATE`, no `LOCK`
- `hyprctl layers`: only `omarchy-background` + `omarchy-bar`, no lock layer
- desktop fully usable; single quickshell instance, no crash, no coredump
`SUPER+CTRL+L` and `omarchy-shell lock lock` both answer `ok` and nothing
happens. Only `omarchy restart shell` clears it (fresh instance reports
`locked:false`).
### Mechanism
`requestSessionLock()` early-returns on `sessionLock.locked || sessionLock.secure`
— the same L64 guard as #6888. Here it is a stale `locked`, left behind by a
previous successful lock→unlock cycle (observed twice: the next lock after any
completed unlock cycle no-ops; intermittently otherwise). The `WlSessionLock`
model object keeps `locked=true` after the compositor has released, so the
shell concludes a lock is in place and declines to create one. Nothing retries
and nothing logs it — the failure is completely silent.
### Suggested fix
Same family as #6888's: the shell needs to reconcile the model with the
compositor instead of trusting it — e.g. treat `locked && !sessionLocked`
with no request in flight as desync (re-read/probe rather than early-return),
and/or bound the spin with a loud failure. Happy to test a build.
### Environment
- omarchy 4.0.0.alpha, quickshell 0.3.2 (omarchy-distributed), Hyprland 0.56.2
- ThinkPad P16s Gen 4 AMD, single external display (clamshell, docked), realScreens:1
- Local mitigation in use: a 30 s user timer watches for
`locked && !sessionLocked && !requested && !authenticating` persisting ~90 s
and restarts the shell (proven reset, zero false positives by construction:
idle shows `locked:false`, every engaged lock shows `requested`/`authenticating`/`sessionLocked`).
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
- Duplicate ofR-5240LockService reports self-contradictory state: isLocked=true while status shows locked components all false· decided by agents · verified
- Fixed bypr/14823· confirmed
- Related PRpr/14911· 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.