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.
omarchy update` aborts on the final migration (1788619462, "Hand Hermes Desktop the Omarchy theme as a skin"
Reported by SavagePossum · filed Sep 11, 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
- CPU: AMD Ryzen 7 5825U with Radeon Graphics - GPU: AMD/ATI Barcelo (amdgpu), Hyprland 0.56.2 - Kernel: 7.2.3-arch1-3 (x86_64) - Distro: Omarchy 4.0.3-1 (channel: stable) - Desktop: Hyprland via SDDM
What's wrong?
Summary
omarchy update aborts on the final migration (1788619462, "Hand Hermes
Desktop the Omarchy theme as a skin") with:
Hermes skin source missing: /root/.local/state/omarchy/current/theme/hermes.yaml
Select an Omarchy theme first.The migration runs under sudo (so $HOME=/root), but the user's theme
state lives under $HOME/.local/state/omarchy/current/theme/ (e.g./home/alex/.local/state/...). The skin file is never generated under
root's home, so the migration reports a missing source and fails the whole
update wrapper.
The migration's marker file is still created, so subsequent updates pass the
step — but the theme handover to Hermes never actually happens, and the
first update after upgrading to this migration always fails.
Steps to reproduce
- Fresh-ish system on Omarchy 4.0.3 (stable), theme
tokyo-night,
hermes-desktop installed.
2. Run sudo omarchy update -y.
3. The update proceeds through package upgrades and dozens of migrations,
then fails on migration 1788619462 with the "Hermes skin source
missing" error above, and the update wrapper exits with
"Something went wrong during the update!".
Expected behavior
The theme handover migration should locate the active theme state under the
logged-in user's home (or otherwise render the skin) and succeed, soomarchy update completes end to end.
System details
- CPU: AMD Ryzen 7 5825U with Radeon Graphics
- GPU: AMD/ATI Barcelo (amdgpu), Hyprland 0.56.2
- Kernel: 7.2.3-arch1-3 (x86_64)
- Distro: Omarchy 4.0.3-1 (channel: stable)
- Desktop: Hyprland via SDDM
Notes / evidence
- The active theme state exists under the user home:
/home/alex/.local/state/omarchy/current/theme/ (theme.name = tokyo-night),
but no hermes.yaml is generated there by this migration.
- The migration (/usr/share/omarchy/migrations/1788619462.sh) calls
omarchy-theme-set-hermes --activate, which reads
$HOME/.local/state/omarchy/current/theme/hermes.yaml. Under sudo,
$HOME=/root, where no theme state exists.
- After the failure, the migration marker
/home/alex/.local/state/omarchy/migrations/1788619462.sh is present, so
the next update skips it and no longer fails on this step.
- Full debug log: /tmp/omarchy-bug-report.log.
View raw text
### System details - CPU: AMD Ryzen 7 5825U with Radeon Graphics - GPU: AMD/ATI Barcelo (amdgpu), Hyprland 0.56.2 - Kernel: 7.2.3-arch1-3 (x86_64) - Distro: Omarchy 4.0.3-1 (channel: stable) - Desktop: Hyprland via SDDM ### What's wrong? ## Summary `omarchy update` aborts on the final migration (1788619462, "Hand Hermes Desktop the Omarchy theme as a skin") with: ``` Hermes skin source missing: /root/.local/state/omarchy/current/theme/hermes.yaml Select an Omarchy theme first. ``` The migration runs under `sudo` (so `$HOME=/root`), but the user's theme state lives under `$HOME/.local/state/omarchy/current/theme/` (e.g. `/home/alex/.local/state/...`). The skin file is never generated under root's home, so the migration reports a missing source and fails the whole update wrapper. The migration's marker file is still created, so subsequent updates pass the step — but the theme handover to Hermes never actually happens, and the first update after upgrading to this migration always fails. ## Steps to reproduce 1. Fresh-ish system on Omarchy 4.0.3 (stable), theme `tokyo-night`, `hermes-desktop` installed. 2. Run `sudo omarchy update -y`. 3. The update proceeds through package upgrades and dozens of migrations, then fails on migration `1788619462` with the "Hermes skin source missing" error above, and the update wrapper exits with "Something went wrong during the update!". ## Expected behavior The theme handover migration should locate the active theme state under the logged-in user's home (or otherwise render the skin) and succeed, so `omarchy update` completes end to end. ## System details - CPU: AMD Ryzen 7 5825U with Radeon Graphics - GPU: AMD/ATI Barcelo (amdgpu), Hyprland 0.56.2 - Kernel: 7.2.3-arch1-3 (x86_64) - Distro: Omarchy 4.0.3-1 (channel: stable) - Desktop: Hyprland via SDDM ## Notes / evidence - The active theme state exists under the user home: `/home/alex/.local/state/omarchy/current/theme/` (theme.name = `tokyo-night`), but no `hermes.yaml` is generated there by this migration. - The migration (`/usr/share/omarchy/migrations/1788619462.sh`) calls `omarchy-theme-set-hermes --activate`, which reads `$HOME/.local/state/omarchy/current/theme/hermes.yaml`. Under sudo, `$HOME=/root`, where no theme state exists. - After the failure, the migration marker `/home/alex/.local/state/omarchy/migrations/1788619462.sh` is present, so the next update skips it and no longer fails on this step. - Full debug log: `/tmp/omarchy-bug-report.log`.
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:43 UTC