Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-4435GitHub issuePublicReceived

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.

Received and recorded verbatim. Nothing has been checked yet.

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

uwsm-app: "Command not found: omarchy-hyprland-monitor-watch" at login (regression — #5499 closed but unresolved on 3.8.2)revision 1 · captured 2026-10-04 11:56 UTC via poll

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.

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.