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-update: pacman replaces /usr/share/omarchy/shell under the running Quickshell, and the failed hot reload makes the post-update restart abort (FATAL: QPixmap)
Reported by shawnyeager · filed Aug 12, 2026Closed upstream on 2026-08-12 by the merge of PR #6751 (closed by dhh). GitHub close reason: completed.
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?
- Not yet mapped to any requirement or component.
- 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?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
System details
AMD Ryzen 5 7640U / Radeon 760M (Phoenix1), Omarchy 4.0.0.r1676.g0fcdd71-1, kernel 7.1.8-arch1-3, quickshell-git 0.3.0.r20.g28771c7-1, qt6-base 6.11.1.
What's wrong
omarchy-update lets pacman replace /usr/share/omarchy/shell/* while the running Quickshell is still watching those files. Quickshell notices the files vanish mid-transaction, attempts a hot reload, and fails:
WARN qml: default shell.json load failed: 2 path=/usr/share/omarchy/config/omarchy/shell.json
WARN quickshell.qmlscanner: Failed to open file "/usr/share/omarchy/shell/shell.qml"
INFO: Reloading configuration...
ERROR: Failed to load configuration
ERROR: caused by @shell.qml[-1:-1]: File not foundSeconds later omarchy-restart-shell sends its IPC kill, and the shell sometimes aborts instead of exiting cleanly:
INFO: Exiting due to IPC request.
FATAL: QPixmap: Must construct a QGuiApplication before a QPixmap
ERROR: Quickshell has crashed under pid 276796
ERROR: Quickshell has been restarted.The user sees the Quickshell crash dialog after an update, and each crash leaves a ~25 MB coredump. The bar does come back, so the damage is cosmetic plus disk.
Frequency
From my journal, 17 omarchy-update runs since 2026-08-09:
| Updates | Failed shell reload | Crashed |
|---|---|---|
| 7 | no | 0 |
| 10 | yes | 3 |
Every crash follows a failed reload. Not every failed reload crashes.
Root cause (Quickshell side)
The failed reload spawns Quickshell's reload popup, which creates a second EngineGeneration. EngineGeneration::currentGeneration() returns null unless exactly one generation exists, so IpcKillCommand::exec() falls back to a bare QCoreApplication::exit(0) instead of the graceful generation->quit(). launch() then runs delete app before its stack-local RootWrapper destructs, so the QML graph is torn down with no QGuiApplication alive, and the first GUI resource touched (MouseArea.cursorShape → QCursor → QPixmap) calls qFatal.
I am filing the ordering bug against Quickshell separately. This issue is about the trigger.
Verified with an isolated Quickshell instance and a 15-line QML config, no Omarchy config involved:
| Run | Config state at IPC kill | Result |
|---|---|---|
| control ×1 | healthy | clean exit |
| test ×3 | failed reload pending | FATAL: QPixmap |
| test ×3 | failed reload pending, QS_NO_RELOAD_POPUP=1 | clean exit |
Steps to reproduce
- Run
omarchy-updateon a machine whose update includes a newomarchypackage. - Watch
journalctl -t omarchy-shell -fwhile pacman runs. - Observe
Failed to load configurationduring the pacman transaction, then theFATAL: QPixmapon the restart.
Suggested fix
Stop the shell before pacman replaces /usr/share/omarchy/shell, then start it after, instead of restarting it afterwards and letting the file watcher fire mid-transaction. That removes the failed reload, and with it the crash, regardless of when Quickshell fixes the shutdown ordering.
omarchy-update-system-pkgs:19 is where the --overwrite '/usr/share/omarchy/*' transaction runs; omarchy-restart-shell:67 is where the kill is sent afterwards.
View raw text
### System details AMD Ryzen 5 7640U / Radeon 760M (Phoenix1), Omarchy 4.0.0.r1676.g0fcdd71-1, kernel 7.1.8-arch1-3, quickshell-git 0.3.0.r20.g28771c7-1, qt6-base 6.11.1. ### What's wrong `omarchy-update` lets pacman replace `/usr/share/omarchy/shell/*` while the running Quickshell is still watching those files. Quickshell notices the files vanish mid-transaction, attempts a hot reload, and fails: ``` WARN qml: default shell.json load failed: 2 path=/usr/share/omarchy/config/omarchy/shell.json WARN quickshell.qmlscanner: Failed to open file "/usr/share/omarchy/shell/shell.qml" INFO: Reloading configuration... ERROR: Failed to load configuration ERROR: caused by @shell.qml[-1:-1]: File not found ``` Seconds later `omarchy-restart-shell` sends its IPC kill, and the shell sometimes aborts instead of exiting cleanly: ``` INFO: Exiting due to IPC request. FATAL: QPixmap: Must construct a QGuiApplication before a QPixmap ERROR: Quickshell has crashed under pid 276796 ERROR: Quickshell has been restarted. ``` The user sees the Quickshell crash dialog after an update, and each crash leaves a ~25 MB coredump. The bar does come back, so the damage is cosmetic plus disk. ### Frequency From my journal, 17 `omarchy-update` runs since 2026-08-09: | Updates | Failed shell reload | Crashed | |---|---|---| | 7 | no | 0 | | 10 | yes | 3 | Every crash follows a failed reload. Not every failed reload crashes. ### Root cause (Quickshell side) The failed reload spawns Quickshell's reload popup, which creates a second `EngineGeneration`. `EngineGeneration::currentGeneration()` returns null unless exactly one generation exists, so `IpcKillCommand::exec()` falls back to a bare `QCoreApplication::exit(0)` instead of the graceful `generation->quit()`. `launch()` then runs `delete app` before its stack-local `RootWrapper` destructs, so the QML graph is torn down with no `QGuiApplication` alive, and the first GUI resource touched (`MouseArea.cursorShape` → `QCursor` → `QPixmap`) calls `qFatal`. I am filing the ordering bug against Quickshell separately. This issue is about the trigger. Verified with an isolated Quickshell instance and a 15-line QML config, no Omarchy config involved: | Run | Config state at IPC kill | Result | |---|---|---| | control ×1 | healthy | clean exit | | test ×3 | failed reload pending | `FATAL: QPixmap` | | test ×3 | failed reload pending, `QS_NO_RELOAD_POPUP=1` | clean exit | ### Steps to reproduce 1. Run `omarchy-update` on a machine whose update includes a new `omarchy` package. 2. Watch `journalctl -t omarchy-shell -f` while pacman runs. 3. Observe `Failed to load configuration` during the pacman transaction, then the `FATAL: QPixmap` on the restart. ### Suggested fix Stop the shell before pacman replaces `/usr/share/omarchy/shell`, then start it after, instead of restarting it afterwards and letting the file watcher fire mid-transaction. That removes the failed reload, and with it the crash, regardless of when Quickshell fixes the shutdown ordering. `omarchy-update-system-pkgs:19` is where the `--overwrite '/usr/share/omarchy/*'` transaction runs; `omarchy-restart-shell:67` is where the kill is sent afterwards.
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.
No decision has been recorded yet.