### System details

AMD Ryzen 9 9950X3D, NVIDIA RTX 5090 (610.57.04), 122 GB RAM, Omarchy 3.8.5, Hyprland 0.56.2-2, kernel 7.2.3-arch1-3, waybar 0.15.0-3, wayland 1.26.0-1. Stock bar config (`diff` against `~/.local/share/omarchy/config/waybar/config.jsonc` is clean). Full `omarchy debug` output available on request.

### What's wrong?

Waybar leaked to **32.1 GB** over one 22-hour session and segfaulted. That part is an upstream Waybar bug and I have reported it there ([Alexays/Waybar#5186](https://github.com/Alexays/Waybar/issues/5186), [my measurements](https://github.com/Alexays/Waybar/issues/5186#issuecomment-5685337673)) — I am not asking Omarchy to fix the leak.

What I would like to raise here is that **Omarchy had no mechanism that limited the damage or recovered from it**, and the gap is small enough to close. The desktop went black, the session looked unrecoverable from the seat, and the box was power-cycled — which killed a 19-hour GPU measurement that had been running headless and perfectly healthy underneath the whole time.

The sequence, from the journal:

```
09:52:26  kernel: waybar[1689]: segfault at 40 ... in libwayland-client.so.0.26.0
09:52:45  systemd-coredump@22: Consumed 18.179s CPU time ... 31.8G memory peak
09:52:46  app-Hyprland-waybar-91fa2d23.scope: ... 22h 35min wall, 32.1G memory peak
```

Note the second line: dumping the 32 GB process cost **another 31.8 GB**. The machine kept logging normally until the power-off 12 minutes later, so nothing here was a kernel-level hang — it was one unbounded user process plus an unbounded core dump.

**Three things I think are Omarchy's side of this:**

1. **The bar is the one desktop helper that is not supervised.** Omarchy already ships `config/systemd/user/swayosd-server.service` with `Restart=always` / `RestartSec=2`, and it earned its keep in this same session — swayosd-server segfaulted **nine times** between 07:53 and 09:37 and silently came back every time (`restart counter is at 8`). Waybar, by contrast, is `exec-once = ! omarchy-toggle-enabled waybar-off && uwsm-app -- waybar` — a transient scope with no restart policy, so when it dies it stays dead. `omarchy-restart-waybar` exists and works perfectly; nothing ever calls it. An unattended bar crash therefore needs a human at the seat, which is exactly the situation where there isn't one.

2. **Nothing bounds a runaway.** `grep -rn 'MemoryMax\|MemoryHigh' ~/.local/share/omarchy/` returns nothing. A `MemoryMax=` on the bar's scope would have turned a lost session into a bar that vanished and (with 1) came back, at a cost of one line.

3. **`systemd-coredump` is unbounded.** There is no `/etc/systemd/coredump.conf.d/` drop-in and no `MemoryMax` on `[email protected]`, so a huge process can be dumped at the price of another copy of itself in RAM at the worst possible moment. On a 16 GB or 32 GB laptop this alone is fatal, independent of which app is leaking. A shipped default like `ProcessSizeMax=4G` plus `MemoryMax=4G` on the dumper template would make a leaking client's death survivable.

**The compute-machine angle**, which is the part I actually care about: an Omarchy box can be doing 20-hour headless GPU work while the desktop is idle. The compute survived the crash fine — what didn't survive was my ability to tell that it had, from a black screen. A documented "your session's UI died, here is how to get it back without rebooting" path (TTY / ssh → `omarchy restart waybar`, or an `omarchy recover session` in the spirit of the existing `omarchy-hw-recover-internal-monitor`) would have saved the run. As it stands, the reflex a black screen produces is the power button, and on this class of machine that reflex is expensive.

**What I did locally**, in case it is a useful starting point rather than something you would rather design yourself: a ~90-line user service that samples the bar's RSS every 60 s, applies `MemoryMax=2G` / `MemorySwapMax=0` to its live scope, relaunches it via `omarchy-restart-waybar` if it is absent (rate-limited to 5/hour, and it will not fight `waybar-off`), and captures `smaps_rollup`/`maps`/fd-table/journal to a case directory the first time it crosses 512 MB — which is what will give the upstream leak report its allocation breakdown. Verified end to end: `pkill -9 -x waybar` → detected and relaunched within one tick → cap reapplied to the new scope. Baseline on this machine is 50-66 MB, so 2 GB is ~30× headroom and should never fire in normal use.

Happy to open a PR for any of this if the shape is agreeable — including just the two defaults (a bound on the bar's scope, a bound on the dumper), which are the parts that would have prevented the outcome regardless of which client leaks next. And thanks for Omarchy; this box runs it happily, which is why the one gap stood out.