omarchy-crash-watch announces the crash its own dispatched agent just reproduced, chaining a fresh agent per hop

[jtavin-smp]

What happened

A genuine Brave SIGTRAP (the --help probe of #8897) produced a crash
notification. Diagnosing it spawned three agent sessions in four minutes, each
dispatched against a crash the previous agent had created while investigating.

11:00:52  brave 781217  SIGTRAP   genuine crash (omarchy-launch-browser --help probe)
11:02:23  agent session A launched, prompt names PID 781217
11:03:38  session A runs `brave ... --help` to confirm the mechanism
11:03:40  brave 787466  SIGTRAP   <- caused by session A
11:04:00  agent session B launched, prompt names PID 787466
11:06:33  brave 792923  SIGTRAP   <- caused by session B, same reason
11:06:xx  agent session C launched, prompt names PID 792923

Each session's cgroup is its own app-Hyprland-xdg-terminal-exec-*.scope from
omarchy-agent-crash, and session A's transcript contains the command that
produced 787466. The crashes are identical in signal, binary and command line to
the one being diagnosed, so the notification is indistinguishable from a real
recurrence.

Why it self-sustains

omarchy-crash-watch:19,80 dedupes per process name over a 60s window. An agent
investigation takes longer than 60s, so a reproduction always lands outside the
window and always announces. The self-exclusion at line 77 only covers
omarchy-crash-* and omarchy-agent-* by process name — the reproduction runs
as brave, so it cannot match.

Honest scope

This is not an unattended infinite loop: each hop needs a click on the toast.
And diagnose-crash/SKILL.md does not instruct reproduction — it documents
symbolizing via coredumpctl dump, which is safe. But reproducing is the obvious
way to confirm a crash whose cause is a command-line flag, and two independent
agent sessions did it unprompted. The gap is that nothing in the pipeline can
tell a diagnosis-caused crash from a new one. #7711 (notification cannot be
dismissed without launching diagnosis) makes clicking the path of least
resistance.

Suggested directions

• Have omarchy-agent-crash export a marker into the agent's environment and
  have omarchy-crash-watch skip coredumps whose COREDUMP_CGROUP is an agent
  scope. This is the targeted fix: it is cgroup-based, so it does not depend on
  process names.
• Or add a note to diagnose-crash/SKILL.md: if you reproduce a crash, say so in
  the report, because it will generate a fresh notification.

Environment

omarchy version      4.0.2-1
try-omarchy-runtime  4.0.2-1  (aarch64 guest, macOS host)
brave-origin-bin     1:1.95.101-1

Filed by Claude Opus 5 (1M context) via Claude Code.