## What happens

Closing the laptop lid dumps core for `1password` on the *next resume*, firing a "Process crashed" notification for a crash that happened an hour earlier. It is intermittent — roughly one lid-close in several.

The crashing process is not the 1Password app. It is the short-lived `1password --lock` helper that `omarchy-system-lock` spawns. The main app (started at login) is unaffected and stays running.

## Expected

Locking 1Password before suspend should not leave a process to be frozen mid-teardown, and should not produce a core dump on resume.

## Mechanism

`omarchy-system-lock:16-20` detaches the helper:

```bash
if pgrep -x "1password" >/dev/null && omarchy-cmd-present 1password; then
  (
    flock -n 9 || exit 0
    timeout --kill-after=1s 3s 1password --lock >/dev/null 2>&1 || true
  ) 9>"${XDG_RUNTIME_DIR:-/tmp}/omarchy-1password-lock.lock" &
fi
```

On lid close the call chain is `switch:on:Lid Switch` (`default/hypr/bindings/utilities.lua:34`) → `omarchy-system-lid-close:17` → `omarchy-system-lock`. Meanwhile logind's delay inhibitor is held by `omarchy-system-sleep-monitor` → `omarchy-system-sleep-lock`, which polls `omarchy-shell lock status` and releases as soon as `secure == true`.

Nothing on the inhibitor path waits for, or reaps, the detached helper. `systemd-sleep` then freezes `user.slice` with it still alive.

Timeline from one failing cycle (`journalctl -o short-precise`):

```
10:25:02.027  systemd-logind[818]: Lid closed.
10:25:02.033  systemd-logind[818]: Suspending...
10:25:02.122  omarchy-shell[16021]: omarchy lock ... lock-requested
10:25:02.675  1password[1369]: Lock state changed: Locked
10:25:02.676  1password[1369]: Locked. Reason: Manual.
10:25:02.692  omarchy-shell[16021]: omarchy lock ... secure=true
10:25:02.827  systemd-sleep[68289]: Successfully froze unit 'user.slice'
10:25:02.835  kernel: PM: suspend entry (deep)
11:27:37      kernel: PM: suspend exit
11:27:37      systemd-coredump[68548]: Process 68066 (1password) ... signal 5/TRAP
```

The helper (PID 68066) had already delivered its lock command at `.675` — its PID falls between `fprintd[68035]` (10:25:02.627) and `omarchy-shell[68257]` (10:25:02.721), confirming it was spawned in that window and survived, frozen, for the full 62-minute suspend. It was killed at the exact second of thaw.

The inverse case, from an earlier cycle the same day, shows the same helper frozen *before* it delivered: the lid closed at 08:47:03 with no `Locked` line, and 1Password only logged `Locked. Reason: Manual.` at 09:21:05 — the resume timestamp. That instance exited cleanly with no core. Whether the helper crashes depends on where in its lifetime the freeze lands, which is why this is intermittent.

## What I can and cannot show

**Proven:** the helper is spawned on the lid-close path, is still alive when `user.slice` freezes, and dies at thaw.

**Inferred:** the specific failure inside it. `SIGTRAP` with `si_code: SI_KERNEL` is the signature of an `int3` executed by the process itself — Chromium's `IMMEDIATE_CRASH()` behind a failed `CHECK()`. The likely proximate cause is the thaw: `CLOCK_REALTIME` jumped an hour, so the wrapping `timeout 3s` fires immediately, and the shutdown path hits a check against IPC state already torn down. I cannot confirm which check.

There is no backtrace to attach, and there cannot be one. 1Password sets `RLIMIT_CORE=0` on itself so vault memory never reaches disk:

```
systemd-coredump[68561]: Resource limits disable core dumping for process 68066
$ grep -i core /proc/1369/limits
Max core file size    0    unlimited    bytes
```

That is correct behavior for a password manager. The practical effect is that these crash notifications can never be diagnosed from the dump itself.

## Reproduction

1. Have 1Password running and unlocked.
2. Close the laptop lid (no external monitor attached, so `omarchy-system-lid-close` locks rather than going clamshell).
3. Wait for suspend, then resume.
4. `coredumpctl list | grep 1password` — intermittently shows a `SIGTRAP` timestamped at the resume second.

## Possible directions

Deliberately not prescribing one, since #6762 shows this script's timing is load-bearing:

- Have `omarchy-system-sleep-lock` also wait on the 1Password helper before releasing the inhibitor, bounded by the budget it already derives.
- Skip the `1password --lock` call on the suspend path entirely. 1Password holds its own logind delay inhibitor (`1password ... sleep "Application cleanup before suspend" delay`) and locks itself on session lock — this machine's log shows `Locked. Reason: Automatic(DeviceLocked)` doing exactly that. The explicit helper looks redundant when the session is locking anyway.

## System

```
Omarchy    4.0.0-1 (stable)
Kernel     7.1.8-arch1-3
Hyprland   0.56.2
1password  8.12.32-33
Hardware   ThinkPad T14 Gen 1
InhibitDelayMaxUSec  15s
```

`omarchy debug` does not exist in 4.0 (`omarchy commands --all` lists no debug subcommand), so the above is gathered by hand.

Filed by Claude Opus 5 via Claude Code.