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-shell SIGSEGV in QQuickItem::mapToScene while Qt synthesizes a context-menu event
Reported by cuphinex · filed Sep 4, 2026Closed upstream on 2026-10-11 by the bot omarchybot, as a duplicate of #6805 (R-1872). GitHub close reason: duplicate.
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
Omarchy's desktop shell (quickshell -n -p /usr/share/omarchy/shell) SIGSEGV'd while handling a mouse event that Qt turned into a context-menu event.
- Time: Fri 2026-09-04 18:09:44 WEST
- PID: 9071
- Signal: SIGSEGV (
si_code: SI_TKILLis Quickshell's crash handler re-raising; the original fault is the frame under<signal handler called>) - Config:
/usr/share/omarchy/shell/shell.qml - Quickshell crash report:
~/.cache/quickshell/crashes/yv2lnukt/report.txt
The wrapper logged the crash and restarted the shell immediately. The bar came back. No user documents were lost.
This is the first recorded quickshell coredump on this machine. Not an OOM: ~9 Gi available, swap unused, no OOM kill.
What was expected
A right-click (or the platform equivalent: two-finger click, mouse menu button) on a shell surface should open a context menu or be ignored. It should not take down the shell.
Steps to reproduce
Not reproduced on demand. The stack is enough to name the path:
- Shell is running (
omarchy-shell/quickshell -n -p /usr/share/omarchy/shell). - A mouse event is delivered to a Quickshell window (bar or panel).
- Qt synthesizes a
QContextMenuEventfrom that mouse event (QWindowPrivate::maybeSynthesizeContextMenuEvent). - While walking the item tree,
QQuickItem::mapToScenesegfaults.
Around the crash: the shell had been up ~2 minutes after a reboot that followed an omarchy-dev upgrade; an MX Master 3S had connected a minute earlier; a grok agent window was focused. That is context, not a demonstrated trigger.
First-party bar buttons accept right-click (shell/Ui/WidgetButton.qml). Several user plugins do too, including quickshell.spotify on the bar. Those plugins are in-process QML, so they can be in the item tree without appearing in the C++ stack. I am not pinning this on a plugin.
Stack
Demangled from the libraries. File/line debuginfo was not applied.
#0 raise (libc) # crash handler re-raise
#1 quickshell # crash handler
#2 <signal handler called>
#3 QQuickItem::mapToScene(QPointF const&) const
#4 QQuickDeliveryAgentPrivate::contextMenuTargets(QQuickItem*, QContextMenuEvent const*) const
#5 QQuickDeliveryAgentPrivate::deliverContextMenuEvent(QContextMenuEvent*)
#6 QQuickDeliveryAgent::event(QEvent*)
#7 QQuickWindow::event(QEvent*)
#8 QCoreApplication::notifyInternal2(QObject*, QEvent*)
#9 QWindowPrivate::maybeSynthesizeContextMenuEvent(QMouseEvent*)
#10 QQuickWindow::event(QEvent*)
#11 QGuiApplicationPrivate::processMouseEvent(...)
#12 QWindowSystemInterface::sendWindowSystemEvents(...)
...
# QCoreApplication::exec()The usual reading of this shape: mapToScene walked a QQuickItem that was already destroyed (or whose parent was). A right-click handler that rebuilds or unloads widgets, then Qt still delivering the synthesized context-menu event to the old item, matches. That is an inference from the stack, not proof of which item.
The coredump contained only the GUI thread.
Related issues (not this)
Looked through the 300 most recent open and 300 most recent closed issues. Other quickshell SIGSEGVs exist with different stacks:
- #9914 PipeWire /
VDMListDelegateDataType::createMissingProperties - #10098 dictation double-click /
IpcHandler::updateRegistration - #7750
QUntypedPropertyBindingon startup - lock / DPMS / EGL crash-loops (#9262, #9843, #9654, …)
None mention mapToScene, contextMenuTargets, or maybeSynthesizeContextMenuEvent. GitHub's issue search API returns 422 for this repo; this was a title grep, not gh search.
System
- Omarchy:
4.0.0.r2015.g4930677-1(omarchy-dev/omarchy-settings-dev, channeledge) - Packages last upgraded: Friday, September 04 2026 at 18:05 (reboot 18:07:41, crash 18:09:44)
- Quickshell: 0.3.1-1
- Qt: qt6-base 6.11.2-3, qt6-declarative 6.11.2-1, qt6-wayland 6.11.2-1
- Hyprland: 0.56.2-2
- Kernel: 7.2.3-arch1-2
- Machine: Lenovo ThinkPad T14 Gen 1, Intel UHD Graphics (i915), 16 GiB, single eDP-1 1920x1080
omarchy-debug --no-sudo --printalso wrote/tmp/omarchy-debug.log
User plugins loaded in this session (from ~/.config/omarchy/shell.json): quickshell.spotify, dizziee.system-updates, mmsbrggr.per-monitor-workspaces, io.github.grichard99.omaproton-vpn, io.github.thisisgm.discord, jonas.agents, shavanced.notification-center, omamail, prettyletto.prettyzap, jonas.icloud-drive.
Filed by Grok 4.6 via Grok.
View raw text
## What happened Omarchy's desktop shell (`quickshell -n -p /usr/share/omarchy/shell`) SIGSEGV'd while handling a mouse event that Qt turned into a context-menu event. - Time: Fri 2026-09-04 18:09:44 WEST - PID: 9071 - Signal: SIGSEGV (`si_code: SI_TKILL` is Quickshell's crash handler re-raising; the original fault is the frame under `<signal handler called>`) - Config: `/usr/share/omarchy/shell/shell.qml` - Quickshell crash report: `~/.cache/quickshell/crashes/yv2lnukt/report.txt` The wrapper logged the crash and restarted the shell immediately. The bar came back. No user documents were lost. This is the first recorded `quickshell` coredump on this machine. Not an OOM: ~9 Gi available, swap unused, no OOM kill. ## What was expected A right-click (or the platform equivalent: two-finger click, mouse menu button) on a shell surface should open a context menu or be ignored. It should not take down the shell. ## Steps to reproduce Not reproduced on demand. The stack is enough to name the path: 1. Shell is running (`omarchy-shell` / `quickshell -n -p /usr/share/omarchy/shell`). 2. A mouse event is delivered to a Quickshell window (bar or panel). 3. Qt synthesizes a `QContextMenuEvent` from that mouse event (`QWindowPrivate::maybeSynthesizeContextMenuEvent`). 4. While walking the item tree, `QQuickItem::mapToScene` segfaults. Around the crash: the shell had been up ~2 minutes after a reboot that followed an `omarchy-dev` upgrade; an MX Master 3S had connected a minute earlier; a grok agent window was focused. That is context, not a demonstrated trigger. First-party bar buttons accept right-click (`shell/Ui/WidgetButton.qml`). Several user plugins do too, including `quickshell.spotify` on the bar. Those plugins are in-process QML, so they can be in the item tree without appearing in the C++ stack. I am not pinning this on a plugin. ## Stack Demangled from the libraries. File/line debuginfo was not applied. ``` #0 raise (libc) # crash handler re-raise #1 quickshell # crash handler #2 <signal handler called> #3 QQuickItem::mapToScene(QPointF const&) const #4 QQuickDeliveryAgentPrivate::contextMenuTargets(QQuickItem*, QContextMenuEvent const*) const #5 QQuickDeliveryAgentPrivate::deliverContextMenuEvent(QContextMenuEvent*) #6 QQuickDeliveryAgent::event(QEvent*) #7 QQuickWindow::event(QEvent*) #8 QCoreApplication::notifyInternal2(QObject*, QEvent*) #9 QWindowPrivate::maybeSynthesizeContextMenuEvent(QMouseEvent*) #10 QQuickWindow::event(QEvent*) #11 QGuiApplicationPrivate::processMouseEvent(...) #12 QWindowSystemInterface::sendWindowSystemEvents(...) ... # QCoreApplication::exec() ``` The usual reading of this shape: `mapToScene` walked a QQuickItem that was already destroyed (or whose parent was). A right-click handler that rebuilds or unloads widgets, then Qt still delivering the synthesized context-menu event to the old item, matches. That is an inference from the stack, not proof of which item. The coredump contained only the GUI thread. ## Related issues (not this) Looked through the 300 most recent open and 300 most recent closed issues. Other quickshell SIGSEGVs exist with different stacks: - #9914 PipeWire / `VDMListDelegateDataType::createMissingProperties` - #10098 dictation double-click / `IpcHandler::updateRegistration` - #7750 `QUntypedPropertyBinding` on startup - lock / DPMS / EGL crash-loops (#9262, #9843, #9654, …) None mention `mapToScene`, `contextMenuTargets`, or `maybeSynthesizeContextMenuEvent`. GitHub's issue search API returns 422 for this repo; this was a title grep, not `gh search`. ## System - Omarchy: `4.0.0.r2015.g4930677-1` (`omarchy-dev` / `omarchy-settings-dev`, channel `edge`) - Packages last upgraded: Friday, September 04 2026 at 18:05 (reboot 18:07:41, crash 18:09:44) - Quickshell: 0.3.1-1 - Qt: qt6-base 6.11.2-3, qt6-declarative 6.11.2-1, qt6-wayland 6.11.2-1 - Hyprland: 0.56.2-2 - Kernel: 7.2.3-arch1-2 - Machine: Lenovo ThinkPad T14 Gen 1, Intel UHD Graphics (i915), 16 GiB, single eDP-1 1920x1080 - `omarchy-debug --no-sudo --print` also wrote `/tmp/omarchy-debug.log` User plugins loaded in this session (from `~/.config/omarchy/shell.json`): `quickshell.spotify`, `dizziee.system-updates`, `mmsbrggr.per-monitor-workspaces`, `io.github.grichard99.omaproton-vpn`, `io.github.thisisgm.discord`, `jonas.agents`, `shavanced.notification-center`, `omamail`, `prettyletto.prettyzap`, `jonas.icloud-drive`. Filed by Grok 4.6 via Grok.
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 10:49 UTC