Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1255GitHub issuePublicReceived

Quickshell SIGSEGV at idle lock: QQuickItem reused across lock-screen windows

Reported by LoveOverEgo · filed Aug 29, 2026 · open at source

In the audited area (lock) — decided by agents · verified. Not validated yet.

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?
AreaIn the audited arealock· 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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. So far: in the audited area (lock) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.

Original report

Quickshell SIGSEGV at idle lock: QQuickItem reused across lock-screen windowsrevision 1 · captured 2026-09-28 21:24 UTC via poll

System details

  • Omarchy: 4.0.1-1
  • Quickshell: 0.3.1-1
  • Qt: 6.11.2 (qt6-base 6.11.2-2, qt6-declarative 6.11.2-1)
  • Multi-monitor setup; preferred display is HDMI-A-1
  • Hybrid graphics: Intel i915 + NVIDIA DRM
  • Idle configuration: screensaver 150 seconds, lock 300 seconds

What's wrong?

Quickshell reproducibly receives SIGSEGV when Omarchy's idle service reaches the five-minute lock timeout.

There are 17 recorded Quickshell coredumps. After the shell automatically restarts, it generally crashes again almost exactly five minutes later, matching idle.lock: 300.

For PID 2338190, all of the following happened in the same second:

omarchy idle 2026-08-29T15:47:43.856Z lock-system: lock-timeout
QQuickItem: Cannot use same item on different windows at the same time.
QQuickItem: Cannot use same item on different windows at the same time.
QQuickItem: Cannot use same item on different windows at the same time.
QQuickItem: Cannot use same item on different windows at the same time.
Process 2338190 (quickshell) terminated with SIGSEGV

Quickshell then restarted itself.

Relevant stack

QQuickItemPrivate::addToDirtyList()
QQuickItemPrivate::dirty(...)
QQuickItem::setParentItem(QQuickItem*)
QQmlBinding::doUpdate(...)
QQmlBinding::update(...)
QQmlNotifier::emitNotify(...)
QQuickItem::itemChange(...)
QQuickItemPrivate::refWindow(QQuickWindow*)  [repeated]
QQuickItem::setParentItem(QQuickItem*)
quickshell
QQmlBinding::doUpdate(...)
...
QQmlTimer::event(QEvent*)
QCoreApplication::exec()

The full Quickshell crash report is stored locally under:

~/.cache/quickshell/crashes/kxkw6nfjkt/report.txt

The matching systemd core is PID 2338190.

Resource and update checks

This is not an OOM event: approximately 31 GiB of memory was available and swap was unused. The kernel journal contains no OOM kill.

The installed Quickshell changed from quickshell-git 0.3.0.r20.g28771c7-2 to packaged quickshell 0.3.1-1 during the Omarchy 4.0.1 update on August 25.

Reproduction

  1. Connect both monitors.
  2. Run the stock Omarchy shell from /usr/share/omarchy/shell/shell.qml.
  3. Leave the machine idle.
  4. At the configured 300-second lock timeout, Quickshell logs the cross-window QQuickItem warnings and crashes.

Expected

The session lock securely covers every connected output, with an independent and valid visual tree for each lock surface.

Actual

Starting the lock produces repeated warnings that the same QQuickItem is being used on different windows, followed immediately by SIGSEGV in Qt Quick's item reparenting/window-reference path.

Likely mechanism and suggested direction

The evidence proves that the lock transition attempts cross-window QQuickItem reuse immediately before the crash. On a multi-monitor session lock, Quickshell creates a lock surface for each output.

It is not yet proven whether the ownership error originates in Omarchy's WlSessionLockSurface composition or in Quickshell 0.3.1's replication of that content. A likely fix direction is to ensure each output receives an independently instantiated lock-screen visual tree rather than reparenting one QQuickItem between windows. If Omarchy's current QML is already using the supported Quickshell pattern, this may need to be forwarded upstream with the included stack.

Related reports checked

  • #6628: lock client dies later with no coredump; different evidence and timing
  • #7145: periodic no-output/placeholder-screen behavior; different trigger
  • #7380: fatal Wayland error during wake/FALLBACK monitor removal; different signal and stack
  • #7750: Qt 6.11.2 startup crash in QUntypedPropertyBinding; different startup trigger and stack
  • #8547: workspace Repeater crash during monitor/workspace churn; different component and stack

No matching issue or pull request was found for the QQuickItem::setParentItem lock-timeout failure.

Filed by GPT-5 via Codex.

View raw text
### System details

- Omarchy: 4.0.1-1
- Quickshell: 0.3.1-1
- Qt: 6.11.2 (`qt6-base 6.11.2-2`, `qt6-declarative 6.11.2-1`)
- Multi-monitor setup; preferred display is `HDMI-A-1`
- Hybrid graphics: Intel i915 + NVIDIA DRM
- Idle configuration: screensaver 150 seconds, lock 300 seconds

### What's wrong?

Quickshell reproducibly receives SIGSEGV when Omarchy's idle service reaches the five-minute lock timeout.

There are 17 recorded Quickshell coredumps. After the shell automatically restarts, it generally crashes again almost exactly five minutes later, matching `idle.lock: 300`.

For PID 2338190, all of the following happened in the same second:

```
omarchy idle 2026-08-29T15:47:43.856Z lock-system: lock-timeout
QQuickItem: Cannot use same item on different windows at the same time.
QQuickItem: Cannot use same item on different windows at the same time.
QQuickItem: Cannot use same item on different windows at the same time.
QQuickItem: Cannot use same item on different windows at the same time.
Process 2338190 (quickshell) terminated with SIGSEGV
```

Quickshell then restarted itself.

### Relevant stack

```
QQuickItemPrivate::addToDirtyList()
QQuickItemPrivate::dirty(...)
QQuickItem::setParentItem(QQuickItem*)
QQmlBinding::doUpdate(...)
QQmlBinding::update(...)
QQmlNotifier::emitNotify(...)
QQuickItem::itemChange(...)
QQuickItemPrivate::refWindow(QQuickWindow*)  [repeated]
QQuickItem::setParentItem(QQuickItem*)
quickshell
QQmlBinding::doUpdate(...)
...
QQmlTimer::event(QEvent*)
QCoreApplication::exec()
```

The full Quickshell crash report is stored locally under:

```
~/.cache/quickshell/crashes/kxkw6nfjkt/report.txt
```

The matching systemd core is PID 2338190.

### Resource and update checks

This is not an OOM event: approximately 31 GiB of memory was available and swap was unused. The kernel journal contains no OOM kill.

The installed Quickshell changed from `quickshell-git 0.3.0.r20.g28771c7-2` to packaged `quickshell 0.3.1-1` during the Omarchy 4.0.1 update on August 25.

### Reproduction

1. Connect both monitors.
2. Run the stock Omarchy shell from `/usr/share/omarchy/shell/shell.qml`.
3. Leave the machine idle.
4. At the configured 300-second lock timeout, Quickshell logs the cross-window QQuickItem warnings and crashes.

### Expected

The session lock securely covers every connected output, with an independent and valid visual tree for each lock surface.

### Actual

Starting the lock produces repeated warnings that the same QQuickItem is being used on different windows, followed immediately by SIGSEGV in Qt Quick's item reparenting/window-reference path.

### Likely mechanism and suggested direction

The evidence proves that the lock transition attempts cross-window QQuickItem reuse immediately before the crash. On a multi-monitor session lock, Quickshell creates a lock surface for each output.

It is not yet proven whether the ownership error originates in Omarchy's `WlSessionLockSurface` composition or in Quickshell 0.3.1's replication of that content. A likely fix direction is to ensure each output receives an independently instantiated lock-screen visual tree rather than reparenting one QQuickItem between windows. If Omarchy's current QML is already using the supported Quickshell pattern, this may need to be forwarded upstream with the included stack.

### Related reports checked

- #6628: lock client dies later with no coredump; different evidence and timing
- #7145: periodic no-output/placeholder-screen behavior; different trigger
- #7380: fatal Wayland error during wake/FALLBACK monitor removal; different signal and stack
- #7750: Qt 6.11.2 startup crash in QUntypedPropertyBinding; different startup trigger and stack
- #8547: workspace Repeater crash during monitor/workspace churn; different component and stack

No matching issue or pull request was found for the `QQuickItem::setParentItem` lock-timeout failure.

Filed by GPT-5 via Codex.

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.

  • Decided by agents · verified: in the audited area (lock)
  • Decided by agents · verified: matches no known issue

The outcome (valid, duplicate, not a bug, …) is not decided yet.