### System details

Intel Core i7-4790, NVIDIA GTX 970, Omarchy `4.0.0.r1761.g7be59e1-1` (omarchy-dev), Hyprland 0.56.2, Chromium 151.0.7922.137, UWSM 0.26.6, kernel 7.1.8-arch1-3

### What's wrong?

After reboot/shutdown from the Omarchy menu, Chromium does not restore all windows. I typically have 3 Chromium windows on different workspaces with many tabs. On restart I get a partial session. If I close the windows first and *then* reboot, the full session comes back.

This is the 3.2.1 workaround from #1329 failing under a heavier session. That issue was closed as “close all windows, `sleep 1`, then shutdown.” One second is not enough for apps to finish writing state, and the current scripts make the race worse by arming poweroff *before* the close/wait.

The failure showed up with Chromium here, but it is not a browser-specific bug. Any app that flushes state on close (browsers, editors, Electron apps) can lose data if the session dies while it is still writing.

#### Steps to reproduce

1. Set Chromium as default browser (“Continue where you left off” / `--restore-last-session`).
2. Open 3 Chromium windows on different workspaces, lots of tabs in each.
3. Leave them open. Omarchy menu → System → Reboot (or Shutdown).
4. After login, open Chromium.

#### Expected

All 3 windows and their tabs restore.

#### Actual

Incomplete restore — not all windows come back. Closing the windows first, waiting for the process to exit, then rebooting restores everything.

#### Evidence

`omarchy-system-reboot` / `omarchy-system-shutdown`:

1. `systemd-run --user --on-active=2s systemctl reboot/poweroff`
2. `omarchy-hyprland-window-close-all` (hyprctl close, no wait for clients)
3. `sleep 1 # Allow apps like Chrome to shutdown correctly`

`omarchy-hyprland-window-close-all` dispatches a close to every window and returns immediately. It does not wait for clients to disappear.

Last shutdown on this machine (2026-08-15, menu → Shutdown → `systemctl poweroff --no-wall`):

- `~/.config/chromium/Default/Sessions/Session_*` mtime **23:58:17** (~1.0 MB)
- `Tabs_*` mtime **23:58:20** (~3.0 MB)
- Chromium scopes gone **23:58:21**
- `systemctl poweroff` requested **23:58:29–31**
- User session fully stopped **23:58:32** (`TimeoutStopSec=5s`)

Also in play:

- `/etc/systemd/system.conf.d/10-faster-shutdown.conf` → `DefaultTimeoutStopSec=5s`
- `/etc/systemd/system/[email protected]/10-faster-shutdown.conf` → `TimeoutStopSec=5s`
- Hyprland does not wait for apps on compositor exit
- Chromium treats an interrupted shutdown as a crash ([crbug 41140760](https://issues.chromium.org/issues/41140760)) and reloads whatever incomplete `Sessions/` snapshot survived. Other apps have the same class of problem (unsaved buffers, incomplete session files).

#### Related closed work (please don’t close this as a duplicate of #1329)

These already covered pieces of the same shutdown race. None of them left a fix that waits for apps to actually exit.

- [#1329](https://github.com/basecamp/omarchy/issues/1329) — *Chromium doesn't shut down correctly on system shutdown/reboot* (closed 2025-11-25). Original report of the crash/restore dialog. Closed as fixed in 3.2.1 with “close all windows, wait 1s, then shutdown.” That is the workaround that is still losing windows here. @vaxerski: Hyprland does not wait for clients; later pointed at [hyprshutdown](https://github.com/hyprwm/hyprshutdown).
- [#1497](https://github.com/basecamp/omarchy/pull/1497) — *Add graceful Hyprland exit for shutdown/restart* (closed, unmerged). SIGTERM → wait 3s → SIGKILL for all apps, then exit Hyprland. Author reported 3s worked “with a decent amount of instances and tabs.” DHH went with the 1s sleep instead.
- [#2841](https://github.com/basecamp/omarchy/pull/2841) — *Chromium browser safe shutdown service* (closed by author, unmerged). Browser-only UWSM shutdown hook. Closed after inconsistent results when the browser stays in a UWSM slice. Special-casing browsers is the approach to avoid.
- [#1886](https://github.com/basecamp/omarchy/pull/1886) — *Change default shutdown timeout to 5sec* (merged, 3.1). Dropped systemd `DefaultTimeoutStopSec` from 90s to 5s so Steam wouldn’t hang the splash. This is the `10-faster-shutdown.conf` that SIGKILLs the user session after 5s, cutting off any app still flushing state.
- [#3443](https://github.com/basecamp/omarchy/issues/3443) — *Omarchy not shutting down properly* (closed). Shutdown stuck on the splash until a hard power-off — the hang #1886 was meant to prevent. Relevant because the 5s hammer is still the backstop after the 1s sleep.

Open, same scripts, different symptoms (not duplicates):

- [#5832](https://github.com/basecamp/omarchy/issues/5832) — shutdown timer can die inside the session scope (dirty unmount).
- [#5105](https://github.com/basecamp/omarchy/issues/5105) — reboot cleared browser logins / keyring, not window layout.

#### Suggested direction

Treat this as a general shutdown sequence, not a browser special case.

Do not arm `systemctl reboot/poweroff` on a 2s timer *before* windows are gone. The intended 3.2.1 order from #1329 was: close everything, wait, *then* power off. The current scripts invert that.

`omarchy-hyprland-window-close-all` should request close on every client and **wait until those clients are actually gone** (or a global timeout fires), then start reboot/shutdown. That matches what @vaxerski said on #1329: Hyprland will not wait; the session has to close windows and wait itself.

A fixed `sleep 1` is too short for a heavy multi-window session. Close-and-wait with a timeout is the same for every app. #1497’s TERM → wait → KILL and [hyprshutdown](https://github.com/hyprwm/hyprshutdown) are both generic versions of that; #2841’s browser-only service is not.