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-804GitHub issuePublicReceived

Shell leaks VRAM on failed EGL context creation, causing Super+Space/menu to silently stop working (NVIDIA, low VRAM)

Reported by wbohannon · filed Sep 8, 2026 · open at source

Partly in the audited area (menu) — 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?
AreaPartly in the audited areamenu· 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: partly in the audited area (menu) — decided by agents · verified; matches no known issue — decided by arbitration. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.

Original report

Shell leaks VRAM on failed EGL context creation, causing Super+Space/menu to silently stop working (NVIDIA, low VRAM)revision 1 · captured 2026-09-28 21:23 UTC via poll

Description

The Omarchy shell (quickshell) leaks VRAM on every failed layer-shell surface creation, instead of releasing the partial allocation. On a system with limited VRAM, this creates a self-reinforcing failure loop: once GPU memory is tight enough that one surface creation fails, every subsequent attempt (e.g. repeatedly pressing Super+Space to open the menu) leaks more VRAM and makes recovery less likely, until omarchy restart shell is run to reclaim it.

Steps to reproduce

  1. Run Omarchy on a machine with a small-VRAM discrete GPU shared across several GPU-memory-hungry apps (in my case: an NVIDIA GTX 1050 with 2GB VRAM, alongside Chromium, VS Code, and other Electron apps).
  2. Let GPU memory usage climb until there isn't enough free VRAM for quickshell to allocate a new EGL/GL context (I hit this around 1729/2048 MiB used, ~85%).
  3. Press SUPER + SPACE (Omarchy menu) — nothing appears.
  4. Keep pressing it — the shell keeps trying, keeps failing, and its own VRAM footprint keeps growing with each failed attempt (in my case: 392 MiB right after a clean shell restart, growing to 702 MiB, then 811 MiB within ~2 minutes, without a single successful render).

Expected behavior

  • A failed layer-shell surface creation should not leak the partially-allocated GPU resources.
  • Ideally, quickshell would detect repeated EGL_BAD_ALLOC / "Failed to create graphics context" failures and either back off, or the Omarchy supervisor would notice sustained failure and auto-restart the shell (similar to the recovery gap noted in #8491, though that issue is about a different trigger — EGL context loss on resume — this one is triggered purely by VRAM exhaustion, no suspend/resume involved).

Actual behavior

SUPER + SPACE (and any other menu/panel toggle) silently does nothing. The keybinding and IPC call both succeed — hyprctl binds shows the bind is correctly registered, and omarchy-menu toggle root returns exit 0 — but no surface is ever rendered. journalctl shows repeated:

WARN: QWaylandGLContext::makeCurrent: eglError: 0x3003
WARN: QRhiGles2: Failed to make context current. Expect bad things to happen.
WARN: Failed to create RHI (backend 2)
ERROR: Failed to create graphics context for qs::wayland::layershell::WlrLayershell(...): "Failed to initialize graphics backend for OpenGL."

Only omarchy restart shell recovers it (until VRAM fills up again).

System details

  • Omarchy: 4.0.3-1
  • Hyprland: 0.56.2
  • Quickshell: 0.3.1
  • Kernel: 7.2.3-arch1-3
  • GPU: NVIDIA GeForce GTX 1050, 2048 MiB VRAM, driver 580.178.04

Notes

Possibly related to #8491 (shell stops rendering after resume-time EGL_BAD_CONTEXT on NVIDIA) — same failure class (Qt RHI/EGL context loss on NVIDIA with no automatic recovery), but a different trigger (VRAM exhaustion under normal use vs. suspend/resume).

View raw text
## Description

The Omarchy shell (`quickshell`) leaks VRAM on every failed layer-shell surface creation, instead of releasing the partial allocation. On a system with limited VRAM, this creates a self-reinforcing failure loop: once GPU memory is tight enough that one surface creation fails, every subsequent attempt (e.g. repeatedly pressing Super+Space to open the menu) leaks more VRAM and makes recovery less likely, until `omarchy restart shell` is run to reclaim it.

## Steps to reproduce

1. Run Omarchy on a machine with a small-VRAM discrete GPU shared across several GPU-memory-hungry apps (in my case: an NVIDIA GTX 1050 with 2GB VRAM, alongside Chromium, VS Code, and other Electron apps).
2. Let GPU memory usage climb until there isn't enough free VRAM for `quickshell` to allocate a new EGL/GL context (I hit this around 1729/2048 MiB used, ~85%).
3. Press `SUPER + SPACE` (Omarchy menu) — nothing appears.
4. Keep pressing it — the shell keeps trying, keeps failing, and its own VRAM footprint keeps growing with each failed attempt (in my case: 392 MiB right after a clean shell restart, growing to 702 MiB, then 811 MiB within ~2 minutes, without a single successful render).

## Expected behavior

- A failed layer-shell surface creation should not leak the partially-allocated GPU resources.
- Ideally, quickshell would detect repeated `EGL_BAD_ALLOC` / "Failed to create graphics context" failures and either back off, or the Omarchy supervisor would notice sustained failure and auto-restart the shell (similar to the recovery gap noted in #8491, though that issue is about a different trigger — EGL context loss on resume — this one is triggered purely by VRAM exhaustion, no suspend/resume involved).

## Actual behavior

`SUPER + SPACE` (and any other menu/panel toggle) silently does nothing. The keybinding and IPC call both succeed — `hyprctl binds` shows the bind is correctly registered, and `omarchy-menu toggle root` returns exit 0 — but no surface is ever rendered. journalctl shows repeated:

```
WARN: QWaylandGLContext::makeCurrent: eglError: 0x3003
WARN: QRhiGles2: Failed to make context current. Expect bad things to happen.
WARN: Failed to create RHI (backend 2)
ERROR: Failed to create graphics context for qs::wayland::layershell::WlrLayershell(...): "Failed to initialize graphics backend for OpenGL."
```

Only `omarchy restart shell` recovers it (until VRAM fills up again).

## System details

- Omarchy: 4.0.3-1
- Hyprland: 0.56.2
- Quickshell: 0.3.1
- Kernel: 7.2.3-arch1-3
- GPU: NVIDIA GeForce GTX 1050, 2048 MiB VRAM, driver 580.178.04

## Notes

Possibly related to #8491 (shell stops rendering after resume-time `EGL_BAD_CONTEXT` on NVIDIA) — same failure class (Qt RHI/EGL context loss on NVIDIA with no automatic recovery), but a different trigger (VRAM exhaustion under normal use vs. suspend/resume).

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: partly in the audited area (menu)
  • Decided by arbitration: matches no known issue

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