## What happened

`omarchy-agent-crash` gets the prompt's `time:` field from the TIME column of `coredumpctl list`:

```bash
when=$(coredumpctl list "$pid" --no-pager --no-legend 2>/dev/null | tail -1 | cut -d' ' -f1-4) || true
```

(`bin/omarchy-agent-crash`, line 30, unchanged on `quattro`.) This gives a wrong time in two ways.

**1. If another core dump is still being processed, the time is replaced by a notice.** While any `[email protected]` is running, `coredumpctl list` prints `-- Notice: N [email protected] unit is running, output may be incomplete.` to stdout after the table. `--no-legend` does not suppress this line, so `tail -1` picks it up and the agent receives:

```
  time:     -- Notice: 1 [email protected]
```

I saw this when a crash toast for one `bash` process was clicked while systemd-coredump was still writing a large Electron core. That dump took 70 s (04:18:47 → 04:19:57).

**2. In all other cases, the time is when the dump finished, not when the process crashed.** The TIME column of `coredumpctl list` is when the journal entry was written, which happens only after the core has been processed. For the Electron crash above:

| Source | Time |
|---|---|
| kernel `traps: electron[…] trap int3` | 04:18:47.717 |
| `COREDUMP_TIMESTAMP` | 04:18:47 |
| `coredumpctl list` TIME (what the prompt shows) | 04:19:53 |

```
$ coredumpctl list <pid> --json=short -q        →  "time": 1790929193879729   (04:19:53)
$ journalctl -o json COREDUMP_PID=<pid> …       →  COREDUMP_TIMESTAMP=1790929127000000   (04:18:47)
```

The 66-second gap matters because the diagnose-crash skill tells the agent to look for files whose mtime "lands on the same second as the crash". The file that explained this crash (the app's stderr log) has an mtime of 04:18:47.735. That matches the real crash time, not the time in the prompt.

## Expected

`time:` should be the moment the process crashed. It should never contain a `coredumpctl` informational message.

## Steps to reproduce

1. Let a process with a large address space crash, so systemd-coredump takes a while to process it. An Electron/Chromium main process took about 66 s here. Confirm that `systemctl list-units 'systemd-coredump@*'` shows a running unit.
2. While that unit is running, run `omarchy agent crash <other-pid>` for another PID from `coredumpctl list`, or click a different crash toast.
3. The prompt shows `time: -- Notice: 1 [email protected]`.
4. After the dump finishes, run `omarchy agent crash` on the large crash itself. The time shown is when the dump finished, not when the process crashed.

I have seen (1) once and (2) every time on this machine. I have not deliberately run the reproduction above.

## Suggested fix

Read `COREDUMP_TIMESTAMP` instead of the list column. This fixes both problems:

```bash
ts=$(journalctl -q --no-pager -o export --output-fields=COREDUMP_TIMESTAMP COREDUMP_PID="$pid" 2>/dev/null \
  | sed -n 's/^COREDUMP_TIMESTAMP=//p' | tail -1)
[[ $ts ]] && when=$(date -d "@$((ts / 1000000))" '+%a %Y-%m-%d %H:%M:%S %Z')
when=${when:-unknown}
```

Tested against the crash above, this returns `Fri 2026-10-02 04:18:47 EDT`, and it leaves `when` empty for a PID with no coredump. If you'd rather make the smallest change, adding `--quiet` to the existing `coredumpctl list` call fixes (1) only. coredumpctl(1) says `--quiet` suppresses messages about "possible in-flight coredumps".

## System

- Omarchy 4.0.4-1
- systemd 261 (261.2-1-arch)
- Linux 7.2.3-arch1-3

Filed by Claude Opus 5.5 via Claude Code.