David Heinemeier HanssonandGitHub
2cc3510d2a
* Offer an AI diagnosis when a process crashes systemd-coredump journals every core dump under a known MESSAGE_ID with the crashing program, pid, and signal as structured fields. omarchy-crash-watch follows that stream and raises a "Process crashed: <program>" toast; clicking it opens omarchy-agent-crash, which briefs the default agent on the crash. The toast goes through omarchy-notification-send --exec rather than a libnotify action, because the shell runs clicks from its own omarchy-exec hint and never emits ActionInvoked. It keeps the default "omarchy-action" app name too, the only one shouldBypassDnd() lets through -- a crash being the last notification worth swallowing. It stays quiet until an agent is configured, since a diagnosis is all it offers. The method lives in a diagnose-crash skill rather than the prompt, so it is edited in one place and works with whichever agent is default. It covers investigating the core, and reporting a confirmed Omarchy bug upstream: scoped to bugs Omarchy controls, searched for duplicates first, only with the user's agreement, and signed with the model and harness that produced it. A migration reaches existing installs, whose skill symlinks and unit enablement would otherwise sit behind one-time setup paths. * Let the diagnosis clean up the core it extracted "Do not modify or delete anything" contradicted the symbolization step right above it, which writes a core to a temp file and deletes it on exit. Read literally, the core survives -- and the same section warns it holds passwords and tokens. The prohibition is about the system, not about your own scratch. * Do not spend a crash toast on a dead notification server The shell owns org.freedesktop.Notifications, so its own crash takes the notification server down with it -- and a shell crash is exactly what you want told about. The toast was sent once into that gap and the dedupe window was recorded regardless, so the rest of the crash loop went quiet for a minute and `journalctl -n 0` never replays what was missed. It now waits for the restarted shell to reclaim the bus name, as omarchy-migrate-notify already does, and only a delivered toast starts the dedupe window.
3.9 KiB
Reporting a Crash Upstream to Omarchy
Read this only after concluding that a crash is genuinely Omarchy's to fix.
Is it even Omarchy's bug?
Be strict here. Omarchy is a configuration layer over Arch Linux, so a crash inside a third-party application — a file manager, a browser, a GNOME or Qt library — is almost always an upstream bug in that project, not in Omarchy.
Omarchy's sphere of control is roughly:
- the
omarchy-*commands - the Quickshell shell and its plugins
- the Hyprland and terminal configuration it ships
- its themes
- its install and migration scripts
- how it packages and configures what it installs
A crash in a program Omarchy merely installs is not an Omarchy bug unless Omarchy's own packaging or configuration is implicated.
If it is not Omarchy's, say so and stop. Suggesting the right upstream project is useful; filing there yourself is not part of this.
Three conditions, all required
- It is a verified bug in Omarchy's sphere, established on evidence. Issues are for verified bugs only. An "is this even a bug?" belongs on the Discord at https://omarchy.org/discord; a feature idea belongs in GitHub Discussions under Suggestions.
- The user has explicitly agreed. Show them the exact title and body you propose, and wait for a yes. Never file unprompted.
- The machine can file it —
gh auth statusmust succeed. Ifghis missing or unauthenticated, do not install or authenticate it. Say so, and hand the user the finished text to submit themselves.
Search before filing
A duplicate issue costs a maintainer more time than no report at all.
gh search issues --repo basecamp/omarchy "<program> crash"
gh issue list --repo basecamp/omarchy --state all --search "<signal> <program>"
Search on the crashing program, the signal, and distinctive symbols from the backtrace — not on the wording of the title you were about to write.
gh search issues accepts only open or closed for --state, and errors on
anything else. Leaving it off searches both, which is what you want here.
Include closed issues. A matching issue closed as fixed, when the crash still reproduces on a current system, is a regression — and reporting that is worth far more than another duplicate.
Adding to an existing report
If a plausible match comes back, read it properly first:
gh issue view <number> --repo basecamp/omarchy --comments
Confirm it is genuinely the same failure. The same program crashing is not the same bug if the trigger or the stack differs.
If it is the same, add to that issue rather than opening a new one — but only when you have something the thread does not already contain: a different reproduction, a symbolized stack where it has none, a narrower trigger, a version where it regressed.
A comment that only says the bug happens to you too is noise. If that is all you have, tell the user so and file nothing.
gh issue comment <number> --repo basecamp/omarchy --body "..."
Filing a new issue
Only when the search turns up nothing that matches:
gh issue create --repo basecamp/omarchy --title "..." --body "..."
Include what happened, what was expected, steps to reproduce, system details from
omarchy version, and diagnostics from omarchy debug --no-sudo --print (which
also writes /tmp/omarchy-debug.log; the interactive omarchy debug can upload
it and print a shareable URL worth including).
gh cannot attach media. If a screenshot would help, save one and give the user
the path to drag into the web form.
Signing
End the issue or comment with a line naming the model and agent harness that produced it, so a human reader knows it was machine-authored:
Filed by <model name> via <agent harness>.
Use your actual model and harness names. If you are not certain of them, say so plainly rather than inventing a version string.