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.
uwsm-app: "Command not found: omarchy-hyprland-monitor-watch" at login (regression — #5499 closed but unresolved on 3.8.2)
Reported by FCygan · filed May 25, 2026Closed upstream on 2026-07-18 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
System details
- Omarchy: 3.8.2 (c3f35c5)
- Kernel: 7.0.9-arch2-1
- Hyprland: 0.55.2-1
- uwsm: 0.26.4-1
- systemd: 260.1-2
- dbus-broker: 37-3
Summary
Same symptom as the previously-closed #5499 (originally reported on 3.6.0): at session start, a critical "App failure" notification appears, and the user journal shows:
uwsm_app-daemon[…]: received: app -- omarchy-hyprland-monitor-watch
uwsm_app-daemon[…]: sent: error 'Error: Command not found: "omarchy-hyprland-monitor-watch"' 1The script exists and is executable at ~/.local/share/omarchy/bin/omarchy-hyprland-monitor-watch, and ~/.config/uwsm/env correctly exports PATH=$OMARCHY_PATH/bin:$PATH (matching the suggested resolution in #5499). The bug still reproduces.
Root cause (with evidence)
The uwsm-app-daemon process is launched before uwsm_env-preloader exports the updated PATH to the systemd user manager, so the daemon inherits a stripped-down PATH and never sees ~/.local/share/omarchy/bin. All subsequent uwsm-app -- omarchy-* calls go through that same daemon and fail to resolve omarchy bin commands by name.
Journal timeline (same second, but order matters):
21:28:57 uwsm_app-daemon[1609]: Launching app daemon
21:28:57 uwsm_env-preloader[1627]: Loading environment from "/home/fcygan/.config/uwsm/env"Inspecting the live daemon's environment confirms it:
$ cat /proc/1609/environ | tr '\0' '\n' | grep ^PATH=
PATH=/usr/local/bin:/usr/binOther autostart entries (hypridle, mako, fcitx5, swaybg) succeed because they live in /usr/bin. Only the omarchy-bin-resident omarchy-hyprland-monitor-watch is affected.
Reproduction
- Log into Omarchy Hyprland session.
- Observe a critical "App failure" notification at startup.
- \
journalctl --user -b 0 | grep monitor-watch\shows the "Command not found" line. - \
cat /proc/\$(pgrep -f uwsm_app-daemon)/environ | tr '\0' '\n' | grep ^PATH=\shows the daemon's PATH is missing the omarchy bin dir.
Possible fixes (just for discussion)
- Use an absolute path in \
default/hypr/autostart.conf\for omarchy-shipped commands. - Install omarchy bin scripts to \
/usr/local/bin\(or symlink) so they're on the default PATH. - Ensure the env-preloader completes before \
uwsm-app-daemon\starts.
Local workaround
Adding \PATH=\${HOME}/.local/share/omarchy/bin:\${PATH}\ in \~/.config/environment.d/omarchy-path.conf\ makes systemd-user load it before any user service starts, so the daemon picks up the right PATH. Stops the notification but isn't a real fix.
View raw text
### System details
- Omarchy: 3.8.2 (c3f35c5)
- Kernel: 7.0.9-arch2-1
- Hyprland: 0.55.2-1
- uwsm: 0.26.4-1
- systemd: 260.1-2
- dbus-broker: 37-3
### Summary
Same symptom as the previously-closed #5499 (originally reported on 3.6.0): at session start, a critical "App failure" notification appears, and the user journal shows:
```
uwsm_app-daemon[…]: received: app -- omarchy-hyprland-monitor-watch
uwsm_app-daemon[…]: sent: error 'Error: Command not found: "omarchy-hyprland-monitor-watch"' 1
```
The script exists and is executable at `~/.local/share/omarchy/bin/omarchy-hyprland-monitor-watch`, and `~/.config/uwsm/env` correctly exports `PATH=$OMARCHY_PATH/bin:$PATH` (matching the suggested resolution in #5499). The bug still reproduces.
### Root cause (with evidence)
The `uwsm-app-daemon` process is launched *before* `uwsm_env-preloader` exports the updated PATH to the systemd user manager, so the daemon inherits a stripped-down PATH and never sees `~/.local/share/omarchy/bin`. All subsequent `uwsm-app -- omarchy-*` calls go through that same daemon and fail to resolve omarchy bin commands by name.
Journal timeline (same second, but order matters):
```
21:28:57 uwsm_app-daemon[1609]: Launching app daemon
21:28:57 uwsm_env-preloader[1627]: Loading environment from "/home/fcygan/.config/uwsm/env"
```
Inspecting the live daemon's environment confirms it:
```
$ cat /proc/1609/environ | tr '\0' '\n' | grep ^PATH=
PATH=/usr/local/bin:/usr/bin
```
Other autostart entries (`hypridle`, `mako`, `fcitx5`, `swaybg`) succeed because they live in `/usr/bin`. Only the omarchy-bin-resident `omarchy-hyprland-monitor-watch` is affected.
### Reproduction
1. Log into Omarchy Hyprland session.
2. Observe a critical "App failure" notification at startup.
3. \`journalctl --user -b 0 | grep monitor-watch\` shows the "Command not found" line.
4. \`cat /proc/\$(pgrep -f uwsm_app-daemon)/environ | tr '\0' '\n' | grep ^PATH=\` shows the daemon's PATH is missing the omarchy bin dir.
### Possible fixes (just for discussion)
- Use an absolute path in \`default/hypr/autostart.conf\` for omarchy-shipped commands.
- Install omarchy bin scripts to \`/usr/local/bin\` (or symlink) so they're on the default PATH.
- Ensure the env-preloader completes before \`uwsm-app-daemon\` starts.
### Local workaround
Adding \`PATH=\${HOME}/.local/share/omarchy/bin:\${PATH}\` in \`~/.config/environment.d/omarchy-path.conf\` makes systemd-user load it before any user service starts, so the daemon picks up the right PATH. Stops the notification but isn't a real fix.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.