### System details

Omarchy 4.0.2-1, Quickshell 0.3.1-1, Hyprland 0.56.2-1, 1password 8.12.34-35, linux 7.1.9-arch1-2.
Laptop, hybrid GPU: Intel CometLake-H UHD (i915, `eDP-1`) + NVIDIA GTX 1650 Mobile (nvidia-open-dkms). Single internal display, no external monitor. Wayland, uwsm session.

### What's wrong

Twice in one night, `quickshell` **wedged while the session was idle-locked**. The process stayed alive and its **IPC kept answering**, but it stopped logging entirely and its `ext-session-lock` client died — leaving Hyprland's crashed-lockscreen failsafe on screen until morning.

The dangerous part is that IPC keeps serving the lock state the shell last reached, so the shell reports a healthy, secure lock long after its locker is gone:

```
$ omarchy-shell lock status
{"locked":true,"requested":true,"pending":false,"sessionLocked":true,
 "secure":true,"realScreens":1,...,"lastEvent":"secure=true",
 "lastEventAt":"2026-09-06T16:02:06.569Z"}    <- 4h39m stale
```

**`omarchy-restart-shell` then refuses to recover it.** Its guard reads exactly that status to decide whether a live locker is worth preserving:

```
Refusing to restart Omarchy shell while the session is locked.
```

So the documented way out of the failsafe is blocked by the very state it exists to clear. The wedge is in the event loop, not the IPC thread, so a dead locker is indistinguishable from a healthy one over IPC. Short of patching a copy of the script, the only way back in is a reboot.

### Occurrences

Both times: shell alive, `solitaryBlockedBy` contains `LOCK`, zero log lines afterwards.

| | locked at | last log line | silent for | shell PID |
|---|---|---|---|---|
| 1 | 20:14:16 | 20:36:43 | 5h16m | 20183 |
| 2 | 02:02:06 | 02:13:08 | 4h39m | 267461 |

No suspend was involved in either — the last suspend was hours before (`PM: suspend exit` at 20:01:13). The system journal has **nothing at all** in the surrounding minute in either case.

### What is *not* the trigger

Both wedges end on an identical pair of lines, which looks like a smoking gun and is not one:

```
1password[1401]: Lock state changed: Locked
omarchy-shell[...]: WARN quickshell.dbus.properties: Error updating property
                    :1.41/StatusNotifierItem/org.kde.StatusNotifierItem:IconName
omarchy-shell[...]: WARN quickshell.dbus.properties: QDBusError(
                    "org.freedesktop.DBus.Error.Failed", "error occurred in Get")
```

`:1.41` is 1Password, whose tray icon changes as it auto-locks. But this pair fires on **all seven** idle lock-timeouts across the two nights, including the five the shell survived. It is simply the last thing logged in every idle-lock cycle, so it is also the last thing logged before silence. Recording it here so nobody else spends time on it.

I could not find anything that distinguishes the two wedges from the five healthy locks. The trigger remains unidentified; the reproducer is only "leave the session idle-locked and wait", which hit twice in two nights here.

### Relationship to #10108

Related but distinct. #10108 is IPC-**dead** (`omarchy-shell is not responding`), follows an S3 resume on a single-GPU NVIDIA desktop, leaves a stale background layer covering the desktop, and fails restart with `An instance of this configuration is already running`.

Here IPC stays **alive** and answers, there is no suspend, the visible result is Hyprland's lock failsafe rather than a stale wallpaper, and restart fails by **refusing** rather than aborting. The common thread is a quickshell that wedges without dying, so the supervision path never fires.

### Suggested fix for the recovery half

Whatever causes the wedge, being unable to recover from it without a reboot seems worth fixing on its own. A `--force` flag on `omarchy-restart-shell` that skips the live-locker guard and goes straight to its existing relock path is enough — someone looking at the failsafe knows the lock screen is dead even when IPC insists otherwise. PR to follow.