### System details

Intel + hybrid graphics ThinkPad on a Lenovo ThinkPad Thunderbolt 4 Dock (3 external outputs over DP MST).
Omarchy 4.0.2-1, Hyprland 0.56.2-1, quickshell 0.3.1-1, qt6-base/qt6-wayland 6.11.2, kernel 7.1.9-arch1-2.

### What's wrong

`omarchy-launch-shell` supervises the shell for exactly the failure described in its own comment:

```
# Quickshell relaunches itself from its signal handlers, but Qt leaves through
# _exit() when the Wayland connection fails, raising no signal: no crash report,
# no relaunch, no bar. Supervise those deaths.
```

The supervision can fail silently. When the compositor is busy reconfiguring
outputs, `compositor_alive` returns a false negative and the loop takes
`compositor_alive || exit 0`. That branch logs nothing. The result is a live
Hyprland session with no bar, no notifications, no OSD, and no trace in the
journal explaining why.

My seat sat in that state for 7.5 hours, from 22:26 to 05:58 the next morning.

### Timeline

The shell died the way #9156 describes, but the trigger was a Thunderbolt dock
hotplug rather than resume from suspend.

```
22:23:55  omarchy-shell[99518]  omarchy lock ... lock-pending: screen-stabilizing
22:23:56  kernel                thunderbolt 1-1: Lenovo ThinkPad Thunderbolt 4 Dock
22:23:57  kernel                pcieport 0000:00:07.2: ASPM: ... reconfiguring
22:24:12  kernel                i915 0000:00:02.0: [drm] *ERROR* failed to lookup MSTB with lct 2, rad 00
22:24:25  at-spi2-registryd     Disabling unresponsive app with pid 99518
22:24:27  kernel                i915 0000:00:02.0: [drm] *ERROR* Failed to get ACT after 3000 ms, last status: 00
22:25:25  at-spi2-registryd     Disabling unresponsive app with pid 99518
22:26:14  uwsm_hyprland.desktop[2136]  error in client communication (pid 99518)
22:26:14  omarchy-shell[99518]  WARN: The Wayland connection experienced a fatal error: Invalid argument
          <nothing further from omarchy-shell for the rest of the boot>
```

The DP MST link failed continuously from 22:24:12 to 22:28:04 while the dock
brought the displays up. The shell was blocked long enough for `at-spi2` to flag
it unresponsive twice before Hyprland dropped the connection.

### Why the supervisor did not relaunch

Working through the branches of the loop, only one silent exit is reachable.

1. **Exit status was 255, not 0.** The installed `libQt6WaylandClient.so.6`
   passes `-1` to `_exit` at both "experienced a fatal error: %s" call sites:

   ```
   78932: mov    $0xffffffff,%edi
   78937: call   *0x9d2ab(%rip)   # 115be8 <_exit@GLIBC_2.2.5>
   ```

   Issue #9156 independently confirms this, logging
   `Omarchy shell exited with status 255; relaunching.` for the same message.
   So `(( status == 0 )) && exit 0` does not apply.

2. **No signal was sent.** Nothing was tearing the session down. Hyprland
   (PID 2136) is still the same process today. So `terminating` was 0.

3. **The two remaining exits both log through `logger -t omarchy-shell`.**
   The journal contains no `relaunching` and no `Giving up on the Omarchy shell`
   line for the entire boot.

That leaves `compositor_alive || exit 0` as the only path taken. Hyprland was
demonstrably alive, so the check was a false negative.

`compositor_alive` calls `hyprctl -j monitors` three times with 0.5 s gaps, so
about one second of budget in total. The kernel was reporting 3000 ms DP MST ACT
timeouts throughout that window. One second is short against a stalled MST
bring-up. The function's own comment anticipates this exact condition:

```
# A compositor busy reconfiguring outputs can miss a query without being gone,
# and that is when the shell dies.
```

### Expected behavior

A session whose compositor is still running should not be left without a shell.
If the supervisor does decide to give up, it should say so in the journal.

### Suggested fixes

1. **Log every give-up path.** Both `exit 0` branches after `run_shell` are
   silent today. A single `logger` line on each would have made this diagnosable
   from the journal alone.

2. **Do not conflate liveness with responsiveness.** The shell dies precisely
   when the compositor is too busy to answer IPC promptly, so an IPC probe is
   the least reliable signal available at that moment. Checking that the
   Hyprland process is alive, or that its socket in
   `$XDG_RUNTIME_DIR/hypr/$HYPRLAND_INSTANCE_SIGNATURE` still exists, would
   answer the actual question.

3. **If the IPC probe stays, widen its budget** well past a single DP MST
   bring-up, and put a `timeout` on `hyprctl` so a hung call cannot consume an
   attempt instantly.

### Related

- #9156 covers the shell death itself, with the identical
  `error in client communication` to `Invalid argument` chain. There the
  supervisor recovered. This report is about the case where it does not, and
  adds a second trigger for that death: Thunderbolt dock hotplug during a lock,
  rather than resume from suspend.
- #10703 covers the neighbouring `status == 0` branch of the same loop. Different
  branch, same outcome of no bar.

No coredump exists for this death, and none is expected, since `_exit` raises no
signal.

---

Filed by Claude Opus 5 via Claude Code.