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.

Back to findings
Known issueKI-261009-4MB1

Lock keyboard-off saves brightness 0 when the light is already off, so unlock restores darkness

OpenReviewedMedium

Medium-severity issue, currently open.

Description

The issue as recorded.

After unlock the keyboard backlight stays at 0. Software restore does not bring back the earlier non-zero level; only the hardware backlight key turns it on. Trigger: keyboard off runs brightnessctl -s set 0 while the LED's current brightness is already 0, so the saved restore value becomes 0. The following wake restore applies that saved 0. The lock plugin's blank path (shell/plugins/lock/Service.qml blankProcess) runs omarchy-brightness-keyboard off. A later blank, from onAuthenticatingPasswordChanged re-arming the idle timer or from a suspend-frozen timer calling armBlankTimer, runs off again before omarchy-system-wake restores. bin/omarchy-brightness-keyboard off always calls brightnessctl -sd "$device" set 0, which saves the current value even when it is already 0. The same mechanism covers two report shapes. In the anchor, a firmware idle timeout zeros the LED before the first off. In the member reports, a second off overwrites the level that the first off saved. Reports: - https://github.com/omacom/omarchy/issues/6667 - https://github.com/omacom/omarchy/issues/12942 - https://github.com/omacom/omarchy/issues/14011

Affected requirements

The requirement(s) this issue violates — click through to the spec.

SW-REQ-261009-GW3G

Fix status

Whether this is simply open, open with a fix proposed, or already fixed upstream — and the pull request / issue that tracks it.

Issue #6667

A fix has been proposed upstream — follow the pull request or issue below to track it.

Vendor
omacom/omarchy
Channel
issue_tracker
Reported in
View pull request / issue
Reference
omacom/omarchy#6667
Reported
2026-08-09
Reported by
human:github/sotoreynah

Reviewed Oct 10, 2026

Reported → Fix proposed → Fixed reflect the upstream disclosure lifecycle: the issue has been reported to the vendor, a pull request or issue is open to fix it, or a released fix is available.

Reported upstream as

1 report in the inbox describes this issue, plus 2 duplicates folded under it.

Severity, explained

Why this is rated the way it is — and the scoring signals behind the rating (each ⓘ explains the term).

MediumRated severity — the impact if this issue is exploited or hit.
why this rating
Risk-rated
risk area
Correctness
Security classification
Not a security surface
CVE surface
None

Where it is

The code the issue lives in — peek the affected function inline to see it in context.

  • omarchy-brightness-keyboard off and restore

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.

Known issue reproducedprofileknown_issue_reproducerprovesSW-REQ-261009-GW3G
Reproducer test
Run it yourself
bash pocs/reproducers/ki-261009-4mb1/repro.sh
Covers (2)
Last run Oct 10, 2026, 2:40 PM

Reproduction steps

Technical steps for your engineers to confirm the issue by hand.

bash pocs/reproducers/ki-261009-4mb1/repro.sh

What protects you, and the fix

What limits your exposure today, and the planned remediation.

What protects you now

Press the hardware keyboard backlight key to turn the light back on. Until a fix lands, avoid a second blank before unlock. A mistyped password re-arms the idle blank and can cause one. A suspend while the screen is already blank can also cause one. Each second blank runs keyboard off again and stores 0.

The fix

In bin/omarchy-brightness-keyboard, make off skip the save when the current level is already 0. Off still sets the LED to 0, and the earlier non-zero saved level stays in place. Restore then returns that earlier level. The lock blank path can also skip keyboard off when the displays are already blank, so off runs once per blank. A person should approve SW-REQ-261009-GW3G, which states that unlock restores the last non-zero keyboard backlight level.

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.

Tracing blast radius…

Evidence trail

The raw evidence manifests behind this finding — superseded by the resolved reproducer above, kept here for traceability.

  • proof/evidence/ki-261009-4mb1.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.

Sign in to discuss this with the proof team.Sign in