Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
omarchy-crash-watch announces the crash its own dispatched agent just reproduced, chaining a fresh agent per hop
Reported by jtavin-smp · filed Sep 15, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
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 792923Each session's cgroup is its own app-Hyprland-xdg-terminal-exec-*.scope fromomarchy-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 coversomarchy-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-crashexport 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-1Filed by Claude Opus 5 (1M context) via Claude Code.
View raw text
## 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.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 13:48 UTC