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.
Lock screen crash: MultiEffect blur with high GPU load causes QML scene crash during plugin reload
Reported by coreySean · filed Sep 5, 2026Closed upstream on 2026-09-20 by bjarneo via an automated message, as a duplicate of #6888 (R-1855). 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
Bug Description
The omarchy-shell lock screen crashes when a local plugin reloads while the compositor is handling a session lock surface, leaving the display locked with no way to authenticate.
Steps to Reproduce
- Leave PC idle until lock screen activates (screensaver at 150s, lock at 300s)
- While locked, have a local plugin (e.g. coco.local-llm) trigger a shell reload
- The lock view's MultiEffect blur reinitializes under GPU pressure, causing the QML scene to crash
- Display remains locked, requiring force power-off
System Details
- Omarchy version: 4.0.2-1
- Hyprland: 0.56.2
- GPU: Intel Raptor Lake-U (i915)
- Display: 1920x1080@60Hz, Wayland
Crash Log
Session from previous boot (journalctl -b -1):
# Lock activated, went secure
08:37:47 omarchy-shell[466958]: DEBUG qml: omarchy lock 2026-09-05T05:37:47.550Z secure=true
# Plugin reload triggers lock service restart
08:40:20 omarchy-shell[466958]: DEBUG qml: Local plugin changed, reloading: coco.local-llm
08:40:20 omarchy-shell[466958]: DEBUG qml: omarchy idle 2026-09-05T05:40:20.499Z service-ready
08:40:20 omarchy-shell[466958]: DEBUG qml: omarchy lock 2026-09-05T05:40:20.758Z lock-stranded: recovering
08:40:20 omarchy-shell[466958]: DEBUG qml: omarchy lock 2026-09-05T05:40:20.758Z lock-requested
# NOTE: secure=true was NEVER logged again — lock surface crashed
# New idle cycle starts (session considered unlocked by idle monitor)
08:40:20 omarchy-shell[466958]: DEBUG qml: omarchy idle 2026-09-05T05:40:20.788Z idle-monitor: active
# Lock triggered again
08:42:59 omarchy-shell[466958]: DEBUG qml: omarchy idle 2026-09-05T05:42:59.078Z lock-system: lock-timeout
08:45:23 omarchy-shell[466958]: DEBUG qml: omarchy idle 2026-09-05T05:45:23.081Z process-start: lock omarchy-system-lock
08:45:23 omarchy-shell[466958]: DEBUG qml: omarchy idle 2026-09-05T05:45:23.233Z process-exit: lock exitCode=0 status=0Root Cause
The MultiEffect in shell/plugins/lock/LockView.qml uses extremely GPU-intensive blur parameters:
- blurMax: 128
- blurMultiplier: 1.25
- blur: 1.0
When reinitializing during a plugin reload while the compositor is handling a session lock swap, the iGPU cannot complete the blur render, causing the QML scene to crash. The lock surface never reached the "secure" state, so the display was left in a locked-but-unusable state.
Suggested Fix
Reduce GPU load in LockView.qml:
MultiEffect {
source: wallpaper
blurEnabled: root.loadBackground && wallpaper.status === Image.Ready
+ blurEnabled: root.loadBackground && wallpaper.status === Image.Ready && wallpaper.width > 0
- blur: 1.0
+ blur: 0.8
- blurMax: 128
+ blurMax: 24
- blurMultiplier: 1.25
+ blurMultiplier: 1.0
- contrast: -0.08
+ contrast: -0.05
}Also add a dark fallback overlay to prevent a blank screen when the blur is unavailable.
This brings the blur from ~160 effective radius (128 * 1.25) down to 24, a ~6x reduction in GPU workload.
View raw text
## Bug Description
The omarchy-shell lock screen crashes when a local plugin reloads while the compositor is handling a session lock surface, leaving the display locked with no way to authenticate.
## Steps to Reproduce
1. Leave PC idle until lock screen activates (screensaver at 150s, lock at 300s)
2. While locked, have a local plugin (e.g. coco.local-llm) trigger a shell reload
3. The lock view's MultiEffect blur reinitializes under GPU pressure, causing the QML scene to crash
4. Display remains locked, requiring force power-off
## System Details
- **Omarchy version:** 4.0.2-1
- **Hyprland:** 0.56.2
- **GPU:** Intel Raptor Lake-U (i915)
- **Display:** 1920x1080@60Hz, Wayland
## Crash Log
Session from previous boot (`journalctl -b -1`):
```
# Lock activated, went secure
08:37:47 omarchy-shell[466958]: DEBUG qml: omarchy lock 2026-09-05T05:37:47.550Z secure=true
# Plugin reload triggers lock service restart
08:40:20 omarchy-shell[466958]: DEBUG qml: Local plugin changed, reloading: coco.local-llm
08:40:20 omarchy-shell[466958]: DEBUG qml: omarchy idle 2026-09-05T05:40:20.499Z service-ready
08:40:20 omarchy-shell[466958]: DEBUG qml: omarchy lock 2026-09-05T05:40:20.758Z lock-stranded: recovering
08:40:20 omarchy-shell[466958]: DEBUG qml: omarchy lock 2026-09-05T05:40:20.758Z lock-requested
# NOTE: secure=true was NEVER logged again — lock surface crashed
# New idle cycle starts (session considered unlocked by idle monitor)
08:40:20 omarchy-shell[466958]: DEBUG qml: omarchy idle 2026-09-05T05:40:20.788Z idle-monitor: active
# Lock triggered again
08:42:59 omarchy-shell[466958]: DEBUG qml: omarchy idle 2026-09-05T05:42:59.078Z lock-system: lock-timeout
08:45:23 omarchy-shell[466958]: DEBUG qml: omarchy idle 2026-09-05T05:45:23.081Z process-start: lock omarchy-system-lock
08:45:23 omarchy-shell[466958]: DEBUG qml: omarchy idle 2026-09-05T05:45:23.233Z process-exit: lock exitCode=0 status=0
```
## Root Cause
The `MultiEffect` in `shell/plugins/lock/LockView.qml` uses extremely GPU-intensive blur parameters:
- `blurMax: 128`
- `blurMultiplier: 1.25`
- `blur: 1.0`
When reinitializing during a plugin reload while the compositor is handling a session lock swap, the iGPU cannot complete the blur render, causing the QML scene to crash. The lock surface never reached the "secure" state, so the display was left in a locked-but-unusable state.
## Suggested Fix
Reduce GPU load in `LockView.qml`:
```diff
MultiEffect {
source: wallpaper
blurEnabled: root.loadBackground && wallpaper.status === Image.Ready
+ blurEnabled: root.loadBackground && wallpaper.status === Image.Ready && wallpaper.width > 0
- blur: 1.0
+ blur: 0.8
- blurMax: 128
+ blurMax: 24
- blurMultiplier: 1.25
+ blurMultiplier: 1.0
- contrast: -0.08
+ contrast: -0.05
}
```
Also add a dark fallback overlay to prevent a blank screen when the blur is unavailable.
This brings the blur from ~160 effective radius (128 * 1.25) down to 24, a ~6x reduction in GPU workload.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.