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.
Silent lock-screen login loop when ~/.config/uwsm/env.d has a shell error (UWSM preloader fails with no UI)
Reported by austrasien · filed Sep 7, 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?
- AreaOutside the audited area· Decided by agents · verified
- 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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Framework Laptop 13 (AMD Ryzen AI 300 Series), AMD Radeon 840M, Omarchy 4.0.2-1, Hyprland 0.56.2, SDDM, uwsm 0.26.7-1, kernel 7.1.9-arch1-2
What's wrong?
A syntax error in any file under ~/.config/uwsm/env.d/ makes uwsm_env-preloader abort. On Omarchy (SDDM + UWSM + Hyprland) the user experience is:
- Boot reaches the Omarchy lock screen (password / fingerprint).
- Correct credentials accepted → brief loading → same lock screen again. Forever.
- No on-screen error. Looks like a wrong password / broken PAM / crashed lock.
- TTY (
Ctrl+Alt+F2) login works; Hyprland never starts (hyprctl→ no instance). - Limine/Snapper snapshot rollback does not help: the bad file lives under
/home.
Omarchy’s own stock UWSM drop-in tells users that overrides belong in ~/.config/uwsm/env.d/* (/usr/share/omarchy/default/uwsm/env.d/10-omarchy), so this is an easy footgun for anyone (or any agent) editing that path.
Journal
uwsm_env-preloader: Loading environment from "/home/<user>/.config/uwsm/env.d/<file>".
uwsm_env-preloader: ...: line 2: :${PATH:}:: bad substitution
uwsm_env-preloader: Env output mark "<hex>" not found in shell output(:${PATH:}: was a typo for :${PATH}: — invalid bash ${VAR:} empty-offset form. Any sourcing error reproduces the same loop.)
Renaming in place to *.broken / *.bak still fails: UWSM’s source_dir loads every ls entry in env.d/. The file must be moved out of env.d/ entirely.
Steps to recreate
- Put a bad shell fragment in
~/.config/uwsm/env.d/99-bad(e.g.case ":${PATH:}:" in *) ;; esac). - Reboot / re-auth at the lock screen.
- Observe endless lock loop; check journal for
uwsm_env-preloader. mvthe file out ofenv.d/→ session starts normally.
What Omarchy could do (even while UWSM fixes upstream)
Upstream report: https://github.com/Vladimir-csp/uwsm/issues/226
Omarchy-side asks:
- Docs / Manual warning —
env.dis session-critical; a typo bricks graphical login with no UI; rename-in-place is not disable; TTY + journal is the recovery path; Snapper won’t save you if the file is in/home. - Visible failure — if the UWSM session fails to start after successful auth, surface something on the greeter/lock (or a one-shot notify on TTY) instead of a silent re-lock.
- Optional: ship or document a tiny
env.dpreflight (bash -n/ source in a subshell) before logout.
Happy to test any Omarchy-side messaging/docs changes.
View raw text
### System details
Framework Laptop 13 (AMD Ryzen AI 300 Series), AMD Radeon 840M, Omarchy 4.0.2-1, Hyprland 0.56.2, SDDM, uwsm 0.26.7-1, kernel 7.1.9-arch1-2
### What's wrong?
A syntax error in any file under `~/.config/uwsm/env.d/` makes `uwsm_env-preloader` abort. On Omarchy (SDDM + UWSM + Hyprland) the user experience is:
1. Boot reaches the Omarchy lock screen (password / fingerprint).
2. Correct credentials accepted → brief loading → **same lock screen again**. Forever.
3. No on-screen error. Looks like a wrong password / broken PAM / crashed lock.
4. TTY (`Ctrl+Alt+F2`) login works; Hyprland never starts (`hyprctl` → no instance).
5. Limine/Snapper snapshot rollback does **not** help: the bad file lives under `/home`.
Omarchy’s own stock UWSM drop-in tells users that overrides belong in `~/.config/uwsm/env.d/*` (`/usr/share/omarchy/default/uwsm/env.d/10-omarchy`), so this is an easy footgun for anyone (or any agent) editing that path.
#### Journal
```text
uwsm_env-preloader: Loading environment from "/home/<user>/.config/uwsm/env.d/<file>".
uwsm_env-preloader: ...: line 2: :${PATH:}:: bad substitution
uwsm_env-preloader: Env output mark "<hex>" not found in shell output
```
(`:${PATH:}:` was a typo for `:${PATH}:` — invalid bash `${VAR:}` empty-offset form. Any sourcing error reproduces the same loop.)
Renaming in place to `*.broken` / `*.bak` still fails: UWSM’s `source_dir` loads **every** `ls` entry in `env.d/`. The file must be moved **out** of `env.d/` entirely.
#### Steps to recreate
1. Put a bad shell fragment in `~/.config/uwsm/env.d/99-bad` (e.g. `case ":${PATH:}:" in *) ;; esac`).
2. Reboot / re-auth at the lock screen.
3. Observe endless lock loop; check journal for `uwsm_env-preloader`.
4. `mv` the file out of `env.d/` → session starts normally.
#### What Omarchy could do (even while UWSM fixes upstream)
Upstream report: https://github.com/Vladimir-csp/uwsm/issues/226
Omarchy-side asks:
1. **Docs / Manual warning** — `env.d` is session-critical; a typo bricks graphical login with no UI; rename-in-place is not disable; TTY + journal is the recovery path; Snapper won’t save you if the file is in `/home`.
2. **Visible failure** — if the UWSM session fails to start after successful auth, surface something on the greeter/lock (or a one-shot notify on TTY) instead of a silent re-lock.
3. Optional: ship or document a tiny `env.d` preflight (`bash -n` / source in a subshell) before logout.
Happy to test any Omarchy-side messaging/docs changes.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.
- Out of scopeDecided by agents · verified · 2026-10-09 11:05 UTC