### System details

- **Omarchy:** 4.0.4-1
- **Kernel:** 7.2.5-4-omarchy
- **Hyprland:** 0.56.2-2 (aquamarine 0.15.0)
- **Quickshell:** 0.3.1-1
- **GPU:** NVIDIA GeForce RTX 3070, nvidia-open-dkms 610.57.04
- **Monitor:** Samsung Odyssey G7 (LC32G7xT) on DP-2, single output

### What happens

If the session is locked while the monitor sleeps, the Omarchy shell exits with a fatal Wayland error when the monitor comes back. The wrapper relaunches it, and the new instance puts the lock back up through the stranded-lock path. You see the lock crash and come back.

It has happened on every overnight lock since the first reboot onto 4.0.4 (Sep 26, Sep 28, Sep 29, Sep 30 and Oct 1 here). Before that, with 4.0.3 and kernel 7.2.5-3, the same monitor events happened almost every day for weeks without killing the shell.

### Expected

The lock survives the output going away and coming back. The shell does not exit.

### Steps to reproduce

1. Use a monitor that fully disconnects (drops hotplug) in standby, so Hyprland swaps in its `FALLBACK` placeholder output. A DisplayPort monitor on NVIDIA does this here.
2. Lock with `omarchy system lock`, or let idle lock the session, and leave it until the monitor goes to standby.
3. Wake the monitor.

### What the logs show

The same sequence every time (journal, Oct 1):

```
omarchy-shell: INFO qt.qpa.wayland: There are no outputs - creating placeholder screen
omarchy-shell: DEBUG: Not creating lock surface for screen QScreen(0x76605a631a80, name="") as it is not backed by a valid wayland output.
   ... (repeats while the monitor is gone)
omarchy-shell: WARN quickshell.hyprland.ipc: Got removal for monitor "FALLBACK" which was not previously tracked.
uwsm_hyprland.desktop: error in client communication (pid 3094799)      <- Hyprland drops the shell
omarchy-shell: WARN qt.qpa.wayland: eglSwapBuffers failed with 0x3000, surface: 0x765ff5313d40
omarchy-shell: WARN: The Wayland connection experienced a fatal error: Invalid argument
omarchy-shell: Omarchy shell exited with status 255; relaunching.
```

After the relaunch, the lock plugin logs:

```
DEBUG qml: omarchy lock ... lock-stranded: recovering
DEBUG qml: omarchy lock ... lock-requested
DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing
DEBUG qml: omarchy lock ... secure=true
```

Once (Sep 30) the user typed their password during the restart. The PAM subprocess (`quickshell.service.pam.subprocess`) then segfaulted inside its conversation callback (`pam_authenticate` → `pam_unix` → `pam_prompt` → quickshell → libjemalloc). It looks like fallout from the restart rather than the cause, but it means a password typed at that moment is lost.

### Analysis

Hyprland ends the shell's connection ("error in client communication") about 2 s after it removes the `FALLBACK` output. While the real output was gone, the shell ran on a Qt placeholder screen, and the lock skipped creating surfaces for it. The rendering error (`eglSwapBuffers` 0x3000) comes right before the fatal error, so the shell seems to send something the compositor rejects as an invalid protocol request: a surface still tied to the removed placeholder/`FALLBACK` output, or a lock surface committed against an output that's gone. I don't have a `WAYLAND_DEBUG` trace of the exact request.

This is related to #13812 (the lock reacting to output hotplug while blanked), but the symptom is different: here the shell process dies.

Third-party shell plugins were loaded at the time. The failing path (session lock / output removal) is in core shell code, but I haven't reproduced it with third-party plugins disabled.

### Workaround

Turn off the monitor setting that makes it fully disconnect in standby, so Hyprland never creates `FALLBACK`.

Filed by Claude Opus 5.5 via Claude Code.