Proof Portal

Sign in
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-4477GitHub issuePublicReceived

Waybar crash leaves bar down because it runs as transient UWSM scope

Reported by derekszen · filed Jul 2, 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.

Open at source
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

Waybar crash leaves bar down because it runs as transient UWSM scoperevision 1 · captured 2026-10-04 11:56 UTC via poll

System details

AMD desktop, Omarchy 3.8.2, Hyprland 0.55.4, uwsm 0.26.6, Waybar 0.15.0-2, glib2 2.88.2-1.

What's wrong?

Waybar disappeared and did not recover until I manually started the packaged user service:

systemctl --user start waybar.service

That service has Restart=on-failure and stayed up after being started. The default Omarchy path had been running Waybar as a transient UWSM app scope instead:

User Unit: app-Hyprland-waybar-162b0792.scope
Command Line: /usr/bin/waybar
Signal: 11 (SEGV)
Timestamp: Thu 2026-07-02 00:26:23 CST

The coredump stack was in deleted GLib/GIO mappings:

#0 ... /usr/lib/libglib-2.0.so.0.8800.1 (deleted)
#2 ... /usr/lib/libgio-2.0.so.0.8800.1 (deleted)

Pacman had upgraded GLib earlier, while the Waybar process was long-running:

2026-06-30T23:49:25+0800 upgraded glib2 (2.88.1-1 -> 2.88.2-1)
2026-07-02 00:26:28 app-Hyprland-waybar-162b0792.scope: Consumed ... over 1d 12h 33min wall clock time

I am not claiming the GLib/Waybar coredump itself is an Omarchy bug. The Omarchy-specific issue is that a single Waybar crash leaves the bar down because it is launched as a transient scope with no restart policy. The packaged Waybar unit already includes:

[Service]
ExecStart=/usr/bin/waybar
ExecReload=kill -SIGUSR2 $MAINPID
Restart=on-failure

Current Omarchy code starts/restarts Waybar through uwsm-app instead:

# default/hypr/autostart.conf
exec-once = ! omarchy-toggle-enabled waybar-off && uwsm-app -- waybar

# bin/omarchy-restart-waybar
pkill -9 -x waybar
setsid uwsm-app -- waybar >/dev/null 2>&1 &

That also makes failed manual restarts hard to diagnose because the restart command discards Waybar stderr and exits before proving the child stayed up.

Expected behavior: if Waybar crashes, it should be restarted automatically or at least Omarchy's restart command should use a supervised unit / report failure.

Possible fix direction: start Waybar through the packaged waybar.service or install an Omarchy-managed user service/drop-in with Restart=on-failure, while preserving the existing waybar-off toggle semantics.

View raw text
### System details

AMD desktop, Omarchy 3.8.2, Hyprland 0.55.4, uwsm 0.26.6, Waybar 0.15.0-2, glib2 2.88.2-1.

### What's wrong?

Waybar disappeared and did not recover until I manually started the packaged user service:

```sh
systemctl --user start waybar.service
```

That service has `Restart=on-failure` and stayed up after being started. The default Omarchy path had been running Waybar as a transient UWSM app scope instead:

```
User Unit: app-Hyprland-waybar-162b0792.scope
Command Line: /usr/bin/waybar
Signal: 11 (SEGV)
Timestamp: Thu 2026-07-02 00:26:23 CST
```

The coredump stack was in deleted GLib/GIO mappings:

```
#0 ... /usr/lib/libglib-2.0.so.0.8800.1 (deleted)
#2 ... /usr/lib/libgio-2.0.so.0.8800.1 (deleted)
```

Pacman had upgraded GLib earlier, while the Waybar process was long-running:

```
2026-06-30T23:49:25+0800 upgraded glib2 (2.88.1-1 -> 2.88.2-1)
2026-07-02 00:26:28 app-Hyprland-waybar-162b0792.scope: Consumed ... over 1d 12h 33min wall clock time
```

I am not claiming the GLib/Waybar coredump itself is an Omarchy bug. The Omarchy-specific issue is that a single Waybar crash leaves the bar down because it is launched as a transient scope with no restart policy. The packaged Waybar unit already includes:

```
[Service]
ExecStart=/usr/bin/waybar
ExecReload=kill -SIGUSR2 $MAINPID
Restart=on-failure
```

Current Omarchy code starts/restarts Waybar through `uwsm-app` instead:

```sh
# default/hypr/autostart.conf
exec-once = ! omarchy-toggle-enabled waybar-off && uwsm-app -- waybar

# bin/omarchy-restart-waybar
pkill -9 -x waybar
setsid uwsm-app -- waybar >/dev/null 2>&1 &
```

That also makes failed manual restarts hard to diagnose because the restart command discards Waybar stderr and exits before proving the child stayed up.

Expected behavior: if Waybar crashes, it should be restarted automatically or at least Omarchy's restart command should use a supervised unit / report failure.

Possible fix direction: start Waybar through the packaged `waybar.service` or install an Omarchy-managed user service/drop-in with `Restart=on-failure`, while preserving the existing `waybar-off` toggle semantics.

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.