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.
Suggestion: Use GNU Stow as the Default symlink Manager
Reported by npenza · filed Jul 8, 2025Closed upstream on 2025-11-03 by dhh, as not planned.
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
I believe there's a strong case to be made for adopting [GNU Stow](https://github.com/anishathalye/dotbot) as the default symlink manager in Omarchy.
Why?
While Omarchy's default applications and configurations are thoughtfully considered, users will customise, experiment, and rice their environments to fit their needs. By making GNU Stow the default, we can offer two significant benefits, especially given the impact Omarchy has had in easing new users into Arch Linux.
1. A safer method for managing and versioning personal configurations, and;
2. An accessible introduction to symlinks.
While Omarchy users are free to install GNU Stow (or any other dotfile manager) and manage symlinks on their own, doing so presents a level of overhead. This currently involves manually configuring and relocating files from ~/.config into a ~/.dotfiles structure, with the added complexity of ensuring Omarchy's pre-existing symlinks aren't inadvertently broken.
Adopting GNU Stow as the default would make this process considerably smoother. If configurations were organised in a stow-ready location by default, and the Omarchy manual provided clear guidance on using Stow—including how to optionally synchronise with a GitHub repository—it would lead to a much more intuitive user experience, and a beneficial learning experience.
I am also hoping that recommendation to use GNU Stow and regularly backup of dotfiles, creates for a smoother omarchy-update experience, and reduce the likelihood that files and precious configs are not suddenly lost and irretrievable.
Why GNU Stow?
After looking at some alternatives, including Chezmoi and Dotbot, I found GNU Stow to be the simplest and easiest to use. It remains true to Unix (using symlinks and directory hierarchies) and is relatively lightweight.
Considerations
There are existing links already, particularly around Omarchy's themes, hypr, waybar and wofi configs. I also recommend if we were to adopt this, sticking to the most common structure e.g ~/.dotfiles.
Really keen to hear your thoughts and suggestions on this topic! I think the ultimate goal here is to guide the user in the right direction, so they can confidently back up their dotfiles, and even sync across multiple machines.
View raw text
I believe there's a strong case to be made for adopting **[GNU Stow](https://github.com/anishathalye/dotbot)** as the default symlink manager in Omarchy. **Why?** While Omarchy's default applications and configurations are thoughtfully considered, users will customise, experiment, and rice their environments to fit their needs. By making GNU Stow the default, we can offer two significant benefits, especially given the impact Omarchy has had in easing new users into Arch Linux. 1. A safer method for managing and versioning personal configurations, and; 2. An accessible introduction to symlinks. While Omarchy users are free to install GNU Stow (or any other dotfile manager) and manage symlinks on their own, doing so presents a level of overhead. This currently involves manually configuring and relocating files from `~/.config` into a `~/.dotfiles` structure, with the added complexity of ensuring Omarchy's pre-existing symlinks aren't inadvertently broken. Adopting GNU Stow as the default would make this process considerably smoother. If configurations were organised in a stow-ready location by default, and the Omarchy manual provided clear guidance on using Stow—including how to optionally synchronise with a GitHub repository—it would lead to a much more intuitive user experience, and a beneficial learning experience. I am also hoping that recommendation to use GNU Stow and regularly backup of dotfiles, creates for a smoother `omarchy-update` experience, and reduce the likelihood that files and precious configs are not suddenly lost and irretrievable. **Why GNU Stow?** After looking at some alternatives, including [Chezmoi](https://www.chezmoi.io/) and [Dotbot](https://github.com/anishathalye/dotbot), I found GNU Stow to be the simplest and easiest to use. It remains true to Unix (using symlinks and directory hierarchies) and is relatively lightweight. **Considerations** There are existing links already, particularly around Omarchy's themes, hypr, waybar and wofi configs. I also recommend if we were to adopt this, sticking to the most common structure e.g `~/.dotfiles`. Really keen to hear your thoughts and suggestions on this topic! I think the ultimate goal here is to guide the user in the right direction, so they can confidently back up their dotfiles, and even sync across multiple machines.
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.