Proof Portal

Sign in
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-540GitHub issuePublicDecided· Out of scope

Quickshell launch OSD and NextKey overlay can stick forever under load / interrupted launches

Reported by gjouret · filed Sep 15, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

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

Quickshell launch OSD and NextKey overlay can stick forever under load / interrupted launchesrevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened?

On Omarchy 4.0.3 (Hyprland + Quickshell), two full-screen overlay layers stayed mapped indefinitely and could not be dismissed with Escape/click:

  1. Launch OSD — banner like Launching Voxtype Configure… (omarchy-osd layer)
  2. NextKey — Super-key shortcut overlay stuck visible (next-key layer, full monitor size)

Neither was a normal Hyprland client window. Clearing required omarchy-restart-shell.

This followed a high memory-pressure session (≈3.3 GB RAM machine thrashing) while Voxtype setup/service restarts were interrupted. The point is not that Voxtype failed — overlays owned by the shell should not remain stuck when a launch is interrupted or Super release is lost.

Expected

  • Launch OSD auto-dismisses even if the launched app never appears / is cancelled / shell is under load.
  • NextKey hides if Super is no longer held (or after a short failsafe timeout), and never leaves a permanent full-screen layer.

Actual

  • hyprctl layers showed sticky overlays:
  • namespace: omarchy-osd (fullscreen)
  • namespace: next-key (fullscreen)
  • No normal windows for those UIs; Escape did nothing.

Relevant code (dev checkout)

Launch OSD (shell/services/AppLibrary.qml):

  • Shows with `duration: 0`, so the OSD does not self-expire; only closeLaunchFeedback() → omarchy-shell osd close clears it.
  • There is a 15s launchTimeout, but under severe load timers / IPC can fail, and if osd close is missed there is no secondary failsafe on the OSD service itself.
  • Comment in-file: "the OSD shows with duration 0, so only closeLaunchFeedback() takes it down".

NextKey (next-key plugin hypr/shortcut-hints.lua):

  • on_show / on_hide go through omarchy-shell -q next-key … IPC.
  • Hide depends on Super release being delivered through input.keyboard.key + deferred modifier sampling. If release is dropped under load, state can remain VISIBLE with no timeout to force-hide when modifiers are actually up.

Suggested directions

  1. Give launch OSD a hard max duration (even if duration: 0 means “until closed”), or make the OSD service itself expire sticky launch messages.
  2. Treat failed/non-zero omarchy-shell osd close as retryable; don’t leave launchOsdOpen and the layer out of sync.
  3. NextKey: periodic failsafe — if overlay visible and Super not down, send hide.
  4. Optional: Escape / click-outside dismisses stuck shell overlays.

Environment

  • Omarchy 4.0.3
  • Hyprland + Quickshell shell from linked checkout
  • NextKey plugin installed
  • Low-RAM host (severe zram pressure when this reproduced)

Happy to add logs/hyprctl layers dumps if useful.

View raw text
### What happened?

On Omarchy 4.0.3 (Hyprland + Quickshell), two full-screen overlay layers stayed mapped indefinitely and could not be dismissed with Escape/click:

1. **Launch OSD** — banner like `Launching Voxtype Configure…` (`omarchy-osd` layer)
2. **NextKey** — Super-key shortcut overlay stuck visible (`next-key` layer, full monitor size)

Neither was a normal Hyprland client window. Clearing required `omarchy-restart-shell`.

This followed a high memory-pressure session (≈3.3 GB RAM machine thrashing) while Voxtype setup/service restarts were interrupted. The point is not that Voxtype failed — overlays owned by the shell should not remain stuck when a launch is interrupted or Super release is lost.

### Expected

- Launch OSD auto-dismisses even if the launched app never appears / is cancelled / shell is under load.
- NextKey hides if Super is no longer held (or after a short failsafe timeout), and never leaves a permanent full-screen layer.

### Actual

- `hyprctl layers` showed sticky overlays:
  - `namespace: omarchy-osd` (fullscreen)
  - `namespace: next-key` (fullscreen)
- No normal windows for those UIs; Escape did nothing.

### Relevant code (dev checkout)

**Launch OSD** (`shell/services/AppLibrary.qml`):

- Shows with **`duration: 0`**, so the OSD does not self-expire; only `closeLaunchFeedback()` → `omarchy-shell osd close` clears it.
- There is a 15s `launchTimeout`, but under severe load timers / IPC can fail, and if `osd close` is missed there is no secondary failsafe on the OSD service itself.
- Comment in-file: *"the OSD shows with duration 0, so only closeLaunchFeedback() takes it down"*.

**NextKey** (`next-key` plugin `hypr/shortcut-hints.lua`):

- `on_show` / `on_hide` go through `omarchy-shell -q next-key …` IPC.
- Hide depends on Super release being delivered through `input.keyboard.key` + deferred modifier sampling. If release is dropped under load, state can remain `VISIBLE` with no timeout to force-hide when modifiers are actually up.

### Suggested directions

1. Give launch OSD a hard max duration (even if `duration: 0` means “until closed”), or make the OSD service itself expire sticky launch messages.
2. Treat failed/`non-zero` `omarchy-shell osd close` as retryable; don’t leave `launchOsdOpen` and the layer out of sync.
3. NextKey: periodic failsafe — if overlay visible and Super not down, send `hide`.
4. Optional: Escape / click-outside dismisses stuck shell overlays.

### Environment

- Omarchy `4.0.3`
- Hyprland + Quickshell shell from linked checkout
- NextKey plugin installed
- Low-RAM host (severe zram pressure when this reproduced)

Happy to add logs/`hyprctl layers` dumps if useful.

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 13:37 UTC