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.
Defaults → Browser menu can't reflect the actual xdg default when it's outside the hardcoded list
Reported by PapaPandroni · filed Aug 29, 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?
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. So far: in the audited area (menu) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
What happened
When the XDG default browser is one Omarchy doesn't know about, Defaults → Browser cannot show it, cannot check it, and — if none of the seven known browsers are installed either — offers nothing to select.
On my machine librewolf is the default and chromium is the only browser from Omarchy's list that is installed. The menu renders exactly one row, "Chromium", unchecked. There is no indication that LibreWolf is in fact the default, and no way to pick it back if I switch away.
Expected
The menu reflects the actual xdg-settings default, even when it is a browser outside the built-in list.
Steps to reproduce
- On a system with
chromiuminstalled, also install a browser not in Omarchy's list (librewolf,vivaldi,waterfox, …). xdg-settings set default-web-browser librewolf.desktop- Open the Omarchy menu → Setup → Defaults → Browser.
- Only "Chromium" is listed, unchecked. LibreWolf is absent.
Cause
default/omarchy/omarchy-menu.jsonc:143-149 hardcodes seven rows, each gated on omarchy-cmd-present <browser>, and each checked compares against a short name:
"checked":"[[ \"$(omarchy-default-browser)\" == \"chromium\" ]]"omarchy-default-browser with no args maps seven known desktop ids to those short names, and otherwise falls through to:
*) env -u BROWSER xdg-settings get default-web-browser ;;So for anything outside the list it emits a raw desktop id (librewolf.desktop) in a different format from the short names every checked compares against. No row can ever match, and no row exists for the browser anyway.
Worth noting omarchy-launch-browser already handles this correctly — it reads xdg-settings and resolves Exec= from the desktop file, so LibreWolf launches fine via Super+Shift+Return. It is only the menu that can't represent the state.
Suggested fix
Have omarchy-default-browser accept and report arbitrary .desktop ids rather than a fixed list, and let the menu derive its rows from the installed x-scheme-handler/https handlers (xdg-mime/desktop-file scan) instead of a hardcoded set. That keeps xdg-settings as the single source of truth, consistent with the reasoning in #4340.
System
- Omarchy 4.0.1-1
- chromium 151.0.7922.173-1, librewolf 154.0_2-1
View raw text
### What happened When the XDG default browser is one Omarchy doesn't know about, **Defaults → Browser** cannot show it, cannot check it, and — if none of the seven known browsers are installed either — offers nothing to select. On my machine `librewolf` is the default and `chromium` is the only browser from Omarchy's list that is installed. The menu renders exactly one row, "Chromium", unchecked. There is no indication that LibreWolf is in fact the default, and no way to pick it back if I switch away. ### Expected The menu reflects the actual `xdg-settings` default, even when it is a browser outside the built-in list. ### Steps to reproduce 1. On a system with `chromium` installed, also install a browser not in Omarchy's list (`librewolf`, `vivaldi`, `waterfox`, …). 2. `xdg-settings set default-web-browser librewolf.desktop` 3. Open the Omarchy menu → Setup → Defaults → Browser. 4. Only "Chromium" is listed, unchecked. LibreWolf is absent. ### Cause `default/omarchy/omarchy-menu.jsonc:143-149` hardcodes seven rows, each gated on `omarchy-cmd-present <browser>`, and each `checked` compares against a short name: ``` "checked":"[[ \"$(omarchy-default-browser)\" == \"chromium\" ]]" ``` `omarchy-default-browser` with no args maps seven known desktop ids to those short names, and otherwise falls through to: ```bash *) env -u BROWSER xdg-settings get default-web-browser ;; ``` So for anything outside the list it emits a raw desktop id (`librewolf.desktop`) in a different format from the short names every `checked` compares against. No row can ever match, and no row exists for the browser anyway. Worth noting `omarchy-launch-browser` already handles this correctly — it reads `xdg-settings` and resolves `Exec=` from the desktop file, so LibreWolf launches fine via Super+Shift+Return. It is only the menu that can't represent the state. ### Suggested fix Have `omarchy-default-browser` accept and report arbitrary `.desktop` ids rather than a fixed list, and let the menu derive its rows from the installed `x-scheme-handler/https` handlers (`xdg-mime`/desktop-file scan) instead of a hardcoded set. That keeps `xdg-settings` as the single source of truth, consistent with the reasoning in #4340. ### System - Omarchy 4.0.1-1 - chromium 151.0.7922.173-1, librewolf 154.0_2-1
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
- Related PRpr/5774· confirmed
- Related PRpr/13309· confirmed
- Related PRpr/5553· confirmed
- Related PRpr/12132· confirmed
- Related PRpr/12754· confirmed
- Related PRpr/9430· confirmed
- Related PRpr/8801· confirmed
- Related PRpr/9431· confirmed
- Related PRpr/6606· 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.
- Decided by agents · verified: in the audited area (menu)
- Decided by agents · verified: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.