Proof Portal
Omarchy
ProbeLabsviewing a historical runA 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.
omarchy-system-lock exits 0 when lock engagement fails, leaving the dismissed Lock row silent
Medium-severity issue, currently open.
Description
The issue as recorded.
bin/omarchy-system-lock line 10 runs omarchy-shell lock lock >/dev/null and never checks the exit status. A refused engagement (omarchy-shell exits non-zero) or an absent binary (exit 127) therefore passes silently. The script runs its side-effect steps and exits 0 on every path. The menu Lock row (default/omarchy/omarchy-menu.jsonc:38) dismisses the menu on activation, and no surface reports the failure. The user walks away from a session they believe locked; the WC89 hazard_review (batch D) grades this medium on high impact times near-zero likelihood. pocs/wc89-silent-lock-exit0.sh reproduces it: the real script exits 0 on both failure arms while the control arm confirms the invocation wiring.
Affected requirements
The requirement(s) this issue violates — click through to the spec.
Severity, explained
Why this is rated the way it is — and the scoring signals behind the rating (each ⓘ explains the term).
- why this rating
- Reproducer-confirmed
- CVE surface
- None
Where it is
The code the issue lives in — peek the affected function inline to see it in context.
- bin/omarchy-system-lock (menu Lock row callee, WC89 interface)
How it's proven
The reproducer — an actual test that drives the real code and shows the issue happening. Run it yourself, or peek the test and the source it covers.
./pocs/wc89-silent-lock-exit0.sh
Reproduction steps
Technical steps for your engineers to confirm the issue by hand.
./pocs/wc89-silent-lock-exit0.sh
What protects you, and the fix
What limits your exposure today, and the planned remediation.
What protects you now
Verify a suspicious lock before walking away: run omarchy-hyprland-session-locked (exit 0 locked, 1 unlocked) or look at the lock surface. Re-trigger the failure deliberately in a terminal, where omarchy-system-lock shows the callee stderr directly.
The fix
bin/omarchy-system-lock must propagate the omarchy-shell lock exit instead of exiting 0. The lock component (SYS-REQ-260912-T0XP family) owns engagement and failure surfacing per the WC89 obligation_delegations record. Raise a visible failure surface (desktop notification with a non-zero CLI exit); the menu side stays fire-and-forget by design. Close criterion: pocs/wc89-silent-lock-exit0.sh flips red, with both failure arms exiting non-zero.
Blast radius
If you touch this issue, what else may need re-checking — the requirements it affects and the code and tests that hang off them. Historical view: authored trace links only — automatically derived links aren't reconstructible for past runs.
No authoredcode links reach these requirements in this historical reconstruction. Automatically derived code links aren't reconstructible for past runs, so implementing code may have existed without an authored trace.
Per-requirement evidence
For each requirement this finding touches: the implementing code, verifying tests, and proof obligations that discharge it.
Per-requirement evidence
For each requirement this finding touches: the implementing code, verifying tests, and proof obligations that discharge it.
Evidence trail
The raw evidence manifests behind this finding — superseded by the resolved reproducer above, kept here for traceability.
Evidence trail
The raw evidence manifests behind this finding — superseded by the resolved reproducer above, kept here for traceability.
- proof/evidence/ki-260930-2fbe.yaml
Change history
Every recorded revision of this finding's source file — when it was added, edited, or re-classified, with the diff for each change.
Discussions
Discuss this with the proof team. Nothing changes in your audit automatically — you open a request and a staff member records any outcome inside the thread.