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.
dmenu request lifecycle drops waiters on re-summon, on a busy resultProc, and for doneFile-only requests
Medium-severity issue, currently open.
What this means for you
Plain-language impact — what this issue could mean for your users and your system, before any of the technical detail.
Summoning a menu again before answering the previous one, for example by pressing Super+K several times, leaves the earlier caller waiting forever. Each one stays behind as a background process, and the action that opened it never completes. The same happens when the menu process dies while a caller waits. Later menus still open and work.
Technical description
A second open without close() replaces selectionFile/doneFile/requestActive with no write to the previous done file - the first caller waits forever (SX26/C06/C07; openExistingMenu/openDmenu bodies). This is omacom/omarchy#9057. The behavioural reproducer test/reports/report-cmulr95nw0kqr1gw46i7f50xj.sh drives two real omarchy-menu-select callers through the real Menu.qml open/openDmenu/cancel bodies. The superseded caller never gets its done file and polls forever. Upstream e332dc97 has no cancel-prior guard; PR 9056 adds one.
finishRequest wipes requestActive and both paths BEFORE resultProc.running = true. Quickshell therefore ignores a command change while the previous write runs, and the new selection disappears (SX26/C14; the empty-selectionFile redirect variant is SX26/C15 and HFY2/C36).
Affected requirements
The requirement(s) this issue violates — click through to the spec.
Fix status
Whether this is simply open, open with a fix proposed, or already fixed upstream — and the pull request / issue that tracks it.
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
- #7818
- Reported
- 2026-08-22
- Reported by
- human:github/designgears
- Vendor response
- Fix In Progress view
- Response received
- 2026-10-04
Reviewed Sep 30, 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
2 reports in the inbox describe this issue.
- Superseding a pending omarchy-menu-select leaks a permanent 20 fork/sec busy-wait loop R-1570filed Aug 22, 2026· open upstream· Decided by agents · verified
- Spamming a menu-summoning keybinding (Super+K) leaks orphaned omarchy-menu-select processes R-1237filed Aug 30, 2026· closed upstream as a duplicate· Decided by agents · verified
Severity, explained
Why this is rated the way it is — and the scoring signals behind the rating (each ⓘ explains the term).
- why this rating
- Risk-rated
- risk area
- Correctness
- CVE surface
- None
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_reproducersh test/reports/report-cmulr95nw0kqr1gw46i7f50xj.sh
Reproduction steps
Technical steps for your engineers to confirm the issue by hand.
sh test/reports/report-cmulr95nw0kqr1gw46i7f50xj.sh
What protects you, and the fix
What limits your exposure today, and the planned remediation.
What protects you now
Nothing bounds the wait. A superseded caller, or one whose menu process dies, keeps polling forever: 19 of 20 in a burst on quattro c05d9019. Later summons still work.
The fix
Finish (or sentinel) the outstanding request before replacing its files; queue the write when resultProc is running; treat a doneFile-only request as cancel-only. #9056 (head b7bd59c4) answers a superseded request and fixes the busy-writer race; a deadline in omarchy-menu-select is still needed for a dead menu process.
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.
Touch this finding and you re-check 8 requirements · 3 code files · 1 tests.
- Menu.qml
- omarchy-menu-input
- omarchy-menu-select
- menu-dmenu-test.sh
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.
- pocs/menu-qml-static.sh
- proof/evidence/ki-menu-request-lifecycle.yaml
- test/reports/report-cmulr95nw0kqr1gw46i7f50xj.sh
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.