## Summary

`omarchy-shell` (Quickshell) intermittently crash-loops right after the idle-lock's screen-blank (DPMS off/on) and after hibernate resume, with a fatal Wayland protocol error. Each crash auto-relaunches within ~1s, but the fresh instance frequently hits the same race and crashes again, producing a repeating cycle (black screen → password prompt → black screen...) that can last anywhere from a few seconds to **nearly 50 minutes** in one observed case. Each cycle also re-triggers the lock screen's "stranded lock recovery" path, so the user sees the password prompt repeatedly with no way to reliably get a keystroke in before it cycles again.

## Environment

- Omarchy: 4.0.2-1 (built 2026-08-30)
- Hyprland: 0.56.2-1
- Session: UWSM + SDDM autologin, Wayland
- GPU/display: external monitor (DELL U2419H) over the affected output path

## Steps to reproduce

1. Let the system sit idle past the configured `idle.lock` timeout (default 300s) so the screensaver runs, then the session locks and the display is blanked via `omarchy-brightness-display off` (`hyprctl dispatch 'hl.dsp.dpms({ action = "disable" })'`).
2. Return and wake the display (DPMS re-enable).
3. Sometimes this is clean. Other times `omarchy-shell` crashes and enters a rapid respawn loop.

Also reproduces after resuming from `systemctl hibernate` (same underlying signature).

## Observed log signature (per cycle, repeating every ~12-13s)

```
INFO qt.qpa.wayland: There are no outputs - creating placeholder screen
WARN qt.qpa.services: Failed to register with host portal QDBusError(...): Could not register app ID: Connection already associated with an application ID
WARN: The Wayland connection experienced a fatal error: Invalid argument
WARN qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0
omarchy-shell[<pid>]: Omarchy shell exited with status 255; relaunching.
omarchy-shell[<new-pid>]:   INFO: Launching config: "/usr/share/omarchy/shell/shell.qml"
...
omarchy lock lock-stranded: recovering
omarchy lock lock-requested
omarchy lock lock-pending: screen-stabilizing
omarchy lock secure=true
```

This repeats until either the race happens to resolve cleanly on a relaunch, or the user manages to authenticate during one of the brief live windows.

## Observed real-world occurrences (from journal, single day of use)

- Aug 31 20:48 — 1 cycle (post-hibernate-resume)
- Sep 1 09:20-09:23 — ~9 cycles
- Sep 1 17:13 — 1 cycle (post-hibernate-resume)
- Sep 1 17:25-17:39 — 2 separate runs, ~40+ cycles total, one lasting ~3 minutes before a lucky password entry broke it
- Sep 2 09:26, 10:11-10:16 — multiple cycles (10:16 run triggered by a manual `omarchy restart shell`)
- Sep 2 11:10-12:00 — **continuous for ~50 minutes**, dozens of cycles

## Impact

During a sustained loop, the machine is effectively unusable — the screen only shows content for the brief window right after each relaunch, then blanks again. There is no reliable way to authenticate since the password prompt can disappear mid-entry.

## Workaround attempted

Confirmed that a VT switch (`chvt` away and back) forces the kernel to re-enumerate outputs, which resolves the race when timed right after a hibernate resume. It's not reliably effective against the rapid self-sustaining loop after idle-lock DPMS toggling, since the built-in supervisor already relaunches within ~1s on its own and a fixed-delay VT kick doesn't reliably land during the actual vulnerable window.

## Diagnostics

Full `omarchy-debug --no-sudo --print` output available on request/attached.