### System details

Omarchy: 4.0.4-1 - Kernel: 7.2.5-3-omarchy - systemd: 261 - Hyprland: v0.56.2 - Session: SDDM autologin (`sddm-autologin` PAM stack) -> Hyprland via uwsm - CPU: AMD Ryzen 7 5700G with Radeon Graphics - RAM: 58Gi - Proton Pass: 1.40.0-1 (app reports 1.40.0) - Signal: 8.26.0-1 - `systemd-coredump`: stock defaults (`/etc/systemd/coredump.conf` has no active   settings, so `Compress=yes`, `Storage=external`) — the compression delay below   is therefore the out-of-the-box behaviour, not a local tweak. - `omarchy debug` is not available on 4.0.4-1 (`Unknown Omarchy command`), so   these details were collected by hand.

### What's wrong?

### What happens

`omarchy-crash-watch` tails the journal with `journalctl -f -n 0`, so it only
announces crashes that are journaled while it is running. That filters on when
the **journal entry arrives**, not on when the **crash happened** — and
`systemd-coredump` writes its entry only after it has finished compressing the
core.

For a large process that delay exceeds the time it takes the watcher to restart
in the next session, so the previous session's crash is announced to the new
one. The toast reads as if the program had just crashed at login.

Measured on one logout → login cycle (same boot, user session restart):

| | SIGTERM | `dumped core` journaled | delay |
|---|---|---|---|
| `signal-desktop` (450 MB peak) | 20:50:07 | 20:50:09 | 2 s |
| `Proton Pass` (1 GB peak) | 20:50:07 | **20:50:48** | **41 s** |

`omarchy-crash-watch` was stopped at 20:50:07 and restarted in the new session
at 20:50:15. Signal's entry landed in the gap and was correctly dropped;
Proton Pass's landed 33 s after the new watcher began tailing and was announced.

```
20:50:07.092  systemd[1196]: Stopping proton-pass...
20:50:07.100  systemd[1196]: Stopped Announce process crashes and offer an AI diagnosis.
20:50:07.167  kernel: traps: Proton Pass[1437] trap int3 ip:5771a61ca0fe sp:7fffc93ef580
20:50:09.445  systemd-coredump[17993]: Process 1435 (signal-desktop) of user 1000 dumped core.
20:50:15.586  systemd[1196]: Started Announce process crashes and offer an AI diagnosis.
20:50:48.644  systemd-coredump[17992]: Process 1437 (Proton Pass) of user 1000 dumped core.
20:50:50.070  systemd[1]: systemd-coredump@0-1-17987_25689-0.service: Consumed 24.109s CPU time over 42.892s wall clock time, 20.1G memory peak.
```

### Expected

A crash that happened before the watcher started is not announced, whatever the
core took to compress. The `-n 0` comment in the script ("so a restart does not
re-announce crashes already dealt with") says this is the intent; the mechanism
does not achieve it for slow dumps.

### Reproduce

1. Run any Electron app with ~1 GB RSS under the graphical session (Proton Pass
   and Signal both do this; both trap `int3` on SIGTERM rather than exiting
   cleanly — that part is an upstream bug in those apps, not Omarchy's).
2. Log out and log back in.
3. A few seconds into the new session: `Process crashed: Proton Pass`.

Not reproducible on a cold boot — a different boot's journal is not tailed — so
it only affects logout → login cycles.

### Suggested fix

`systemd-coredump` puts the crash time in `COREDUMP_TIMESTAMP`. Comparing it
against the watcher's own start time and skipping anything older would make the
`-n 0` intent hold regardless of compression time.

### Impact

The misattribution is the real cost: the toast points at the session that just
started, so the obvious suspects are autostart and session setup, while the
crash actually happened on the way out of the previous session. The only
workaround available to a user is `OMARCHY_CRASH_IGNORE`, which also hides that
program's genuine crashes.

### System

- `omarchy version`: 4.0.4-1
- Kernel: 7.2.5-3-omarchy
- systemd 261.2-1-arch
- Session: SDDM **autologin** (`sddm-autologin` PAM stack), Hyprland via uwsm

---

Drafted by Claude Opus 5 via Claude Code.