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-286GitHub issuePublicFixed

Hard lockout after Hyprland crash while idle-locked — lockdead screen has no local recovery

Reported by Dkrynen · filed Sep 20, 2026 · open at source

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

Hard lockout after Hyprland crash while idle-locked — lockdead screen has no local recoveryrevision 1 · captured 2026-09-28 21:23 UTC via poll

Summary

Overnight the session became completely unrecoverable: Hyprland crashed while the Omarchy idle lock was engaged, the watchdog relaunched it as Hyprland --watchdog-fd 4 --safe-mode --locked, and the lockdead screen offered no way back in. Recovery required switching to a TTY and knowing to run hyprctl --instance 0 eval 'hl.clear_crashed_lockscreen()', then manually waking DPMS (hl.dispatch(hl.dsp.dpms("on"))) and restarting the shell.

Timeline (from journal + quickshell logs)

  • 22:58 / 23:03 — idle lock engaged (lock-system: lock-timeout)
  • ~23:10 — amdgpu flooded *ERROR* Not enough memory for command submission! / amdgpu_vm_validate() failed (GPU VM exhaustion — Vulkan llama.cpp jobs were running)
  • 23:10:27 — Hyprland (pid 1459) SIGABRT
  • Watchdog relaunched with --safe-mode --locked → lockdead screen
  • Morning: DPMS panels off, omarchy shell dead, no local unlock possible

Crash backtrace (coredumpctl)

#5  assertImpl (Hyprland)
#6  Render::GL::CHyprOpenGLImpl::beginSimple(monitor, region, renderbuffer, framebuffer)
#7  Render::GL::CHyprGLRenderer::beginFullFakeRenderInternal(...)
#8  Render::IHyprRenderer::beginRender(...)
#9  Render::IHyprRenderer::beginFullFakeRender(...)
#10 Render::IHyprRenderer::makeSnapshotFB(CWindow)
#11 Desktop::View::CWindow::unmapWindow()

The renderer asserted while snapshotting a window during unmap, under amdgpu VM pressure. (Likely a Hyprland upstream issue too, but the user-facing failure is the lockout.)

Expected

A crash while locked should not equal a hard lockout. Either the lockdead screen should document/offer the recovery command, or Omarchy could provide a recovery path (e.g. a documented TTY command, an auto-recovery watchdog for a crashed lock client, or a keybinding that survives safe mode).

Environment

Workaround applied locally

Disabled the whole idle stack via ~/.local/state/omarchy/indicators/stay-awake and raised idle.lock to 604800 in ~/.config/omarchy/shell.json. Note: suspend still force-locks via omarchy-sleep-lock.service regardless of stay-awake — the same crash during a suspend-lock would reproduce the lockout.

View raw text
## Summary

Overnight the session became completely unrecoverable: Hyprland crashed while the Omarchy idle lock was engaged, the watchdog relaunched it as `Hyprland --watchdog-fd 4 --safe-mode --locked`, and the lockdead screen offered no way back in. Recovery required switching to a TTY and knowing to run `hyprctl --instance 0 eval 'hl.clear_crashed_lockscreen()'`, then manually waking DPMS (`hl.dispatch(hl.dsp.dpms("on"))`) and restarting the shell.

## Timeline (from journal + quickshell logs)

- 22:58 / 23:03 — idle lock engaged (`lock-system: lock-timeout`)
- ~23:10 — amdgpu flooded `*ERROR* Not enough memory for command submission!` / `amdgpu_vm_validate() failed` (GPU VM exhaustion — Vulkan llama.cpp jobs were running)
- 23:10:27 — Hyprland (pid 1459) SIGABRT
- Watchdog relaunched with `--safe-mode --locked` → lockdead screen
- Morning: DPMS panels off, omarchy shell dead, no local unlock possible

## Crash backtrace (coredumpctl)

```
#5  assertImpl (Hyprland)
#6  Render::GL::CHyprOpenGLImpl::beginSimple(monitor, region, renderbuffer, framebuffer)
#7  Render::GL::CHyprGLRenderer::beginFullFakeRenderInternal(...)
#8  Render::IHyprRenderer::beginRender(...)
#9  Render::IHyprRenderer::beginFullFakeRender(...)
#10 Render::IHyprRenderer::makeSnapshotFB(CWindow)
#11 Desktop::View::CWindow::unmapWindow()
```

The renderer asserted while snapshotting a window during unmap, under amdgpu VM pressure. (Likely a Hyprland upstream issue too, but the user-facing failure is the lockout.)

## Expected

A crash while locked should not equal a hard lockout. Either the lockdead screen should document/offer the recovery command, or Omarchy could provide a recovery path (e.g. a documented TTY command, an auto-recovery watchdog for a crashed lock client, or a keybinding that survives safe mode).

## Environment

- Omarchy 4.0.4-1 · Hyprland 0.56.2 (v0.56.2, efb5099)
- GEEKOM A8 MAX · Ryzen 9 8945HS · Radeon 780M (amdgpu) · kernel 7.2.5-3-omarchy
- Full `omarchy debug` log: https://gist.github.com/Dkrynen/2efcf39c46feb834eba272af101ed536
- Coredump retained: `coredumpctl info 1459` (Hyprland SIGABRT 2026-09-19 23:10:27)

## Workaround applied locally

Disabled the whole idle stack via `~/.local/state/omarchy/indicators/stay-awake` and raised `idle.lock` to 604800 in `~/.config/omarchy/shell.json`. Note: suspend still force-locks via `omarchy-sleep-lock.service` regardless of stay-awake — the same crash during a suspend-lock would reproduce the lockout.

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

  • Fixed bypr/13490· confirmed

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.