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 fires false positives for Electron utility subprocess crashes (antigravity-ide)
Reported by zaid-kamil · filed Sep 12, 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's wrong
Every time an Antigravity IDE utility subprocess (e.g. node.mojom.NodeService) crashes, omarchy-crash-watch sends a critical notification: "Process crashed: antigravity-ide" — even though these are expected child-process deaths inside an Electron app that gets respawned automatically.
This produces noisy, confusing toasts for a crash the user doesn't need to care about.
Evidence
$ coredumpctl list | grep antigravity-ide | wc -l
2222 antigravity-ide crashes in 12 days, most of them SIGTRAP/SIGSEGV in utility subprocesses — normal Electron child-process churn. Each one triggers a desktop notification.
The crashed process is always a utility subprocess, not the main IDE:
Command Line: /proc/self/exe --type=utility --utility-sub-type=node.mojom.NodeService ...
Control Group: app-org.chromium.Chromium-6826.scopeRoot cause
omarchy-crash-watch (/usr/share/omarchy/bin/omarchy-crash-watch) listens to the systemd-coredump journal and announces every crash matching the user UID. There is:
- No ignore list —
OMARCHY_CRASH_IGNOREis never set, so no process names are filtered. - No distinction between the main process dying and a utility subprocess dying. Electron apps spawn and respawn child processes constantly; their subprocess crashes are not user-facing bugs.
- The dedupe window (
OMARCHY_CRASH_DEDUPE_SECONDS, default 60s) only suppresses repeated crashes of the same name within a minute — it doesn't help when the crashes are spaced hours apart.
Suggested fix
Add a default OMARCHY_CRASH_IGNORE pattern that filters known benign Electron/Chromium subprocess crashes. Something like:
readonly ignore_pattern='^(antigravity-ide|chromium|chromium-browser)$'Or, more precisely, skip crashes where the COREDUMP_COMM differs from the main executable (i.e. it's a subprocess, not the parent). The journal field COREDUMP_EXE vs COREDUMP_COMM can distinguish these.
A user who wants to see all crashes can still set OMARCHY_CRASH_IGNORE="" to override.
System
- Omarchy current (as of 2026-09-12)
- Antigravity IDE (Electron-based, Chromium subprocesses)
- 13Gi RAM, no OOM pressure
Filed by mimo-v2.5 via opencode.
View raw text
## What's wrong Every time an Antigravity IDE utility subprocess (e.g. `node.mojom.NodeService`) crashes, `omarchy-crash-watch` sends a critical notification: **"Process crashed: antigravity-ide"** — even though these are expected child-process deaths inside an Electron app that gets respawned automatically. This produces noisy, confusing toasts for a crash the user doesn't need to care about. ## Evidence ``` $ coredumpctl list | grep antigravity-ide | wc -l 22 ``` 22 antigravity-ide crashes in 12 days, most of them SIGTRAP/SIGSEGV in utility subprocesses — normal Electron child-process churn. Each one triggers a desktop notification. The crashed process is always a utility subprocess, not the main IDE: ``` Command Line: /proc/self/exe --type=utility --utility-sub-type=node.mojom.NodeService ... Control Group: app-org.chromium.Chromium-6826.scope ``` ## Root cause `omarchy-crash-watch` (`/usr/share/omarchy/bin/omarchy-crash-watch`) listens to the systemd-coredump journal and announces **every** crash matching the user UID. There is: 1. **No ignore list** — `OMARCHY_CRASH_IGNORE` is never set, so no process names are filtered. 2. **No distinction** between the main process dying and a utility subprocess dying. Electron apps spawn and respawn child processes constantly; their subprocess crashes are not user-facing bugs. 3. The dedupe window (`OMARCHY_CRASH_DEDUPE_SECONDS`, default 60s) only suppresses repeated crashes of the **same name** within a minute — it doesn't help when the crashes are spaced hours apart. ## Suggested fix Add a default `OMARCHY_CRASH_IGNORE` pattern that filters known benign Electron/Chromium subprocess crashes. Something like: ```bash readonly ignore_pattern='^(antigravity-ide|chromium|chromium-browser)$' ``` Or, more precisely, skip crashes where the `COREDUMP_COMM` differs from the main executable (i.e. it's a subprocess, not the parent). The journal field `COREDUMP_EXE` vs `COREDUMP_COMM` can distinguish these. A user who wants to see all crashes can still set `OMARCHY_CRASH_IGNORE=""` to override. ## System - Omarchy current (as of 2026-09-12) - Antigravity IDE (Electron-based, Chromium subprocesses) - 13Gi RAM, no OOM pressure Filed by mimo-v2.5 via opencode.
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 12:10 UTC