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.
[Proposal] Change the way omarchy handles base-customization/omarchy-defaults
Reported by abenz1267 · filed Aug 30, 2025Closed upstream on 2025-08-31 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.
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?
- Not yet mapped to any requirement or component.
- 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. No decision has been recorded yet.
Original report
Hello everyone!
Since Omarchy has it's own ISO and OPR now, i want to layout a proposal:
Stop Operating In User-Space
Current issues
This means: omarchy should NOT touch or create files in a users homedir. It adds several problems for no benefit really:
- users and the OS (omarchy) touch the same files => this should NOT be a thing to begin with
- configs being overwritten
- added complexity in omarchy scripts in regards to configs
Solution
Simply apply all omarchy-desired customization at a lower level, f.e. need changes in desktop files? Don't touch .local/share/applications => touch /usr/share/applications. This applies to every base customization omarchy wants to ship to users.
Benefits
- doesnt break user configs
- cleans up omarchy scripts regarding configs
- users can't "accidentally" change omarchy-provided files
Since omarchy has it's own repository now, this should be doable just fine as it's a matter of packaging/installation.
That's it!
Regards
View raw text
Hello everyone! Since Omarchy has it's own ISO and OPR now, i want to layout a proposal: *Stop Operating In User-Space* ## Current issues This means: omarchy should NOT touch or create files in a users homedir. It adds several problems for no benefit really: - users and the OS (omarchy) touch the same files => this should NOT be a thing to begin with - configs being overwritten - added complexity in omarchy scripts in regards to configs ## Solution Simply apply all omarchy-desired customization at a lower level, f.e. need changes in desktop files? Don't touch `.local/share/applications` => touch `/usr/share/applications`. This applies to every base customization omarchy wants to ship to users. ## Benefits - doesnt break user configs - cleans up omarchy scripts regarding configs - users can't "accidentally" change omarchy-provided files Since omarchy has it's own repository now, this should be doable just fine as it's a matter of packaging/installation. That's it! Regards
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
Not linked to any known issue, other report or change yet.
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.
No decision has been recorded yet.