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.
omarchy-shell crash-loops after stranded-lock recovery hits a placeholder screen, eventually filling the runtime tmpfs and killing all keybindings
Reported by physicalproblems-dot · filed Sep 2, 2026 · open at source
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?
- 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 (lock) — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
Environment
- omarchy 4.0.2-1
- hyprland 0.56.2-1
- quickshell 0.3.1-1
- Single monitor: HDMI-A-1 (Acer ED270R, 1920x1080@60)
- Arch Linux
Summary
omarchy-shell (Quickshell) entered a crash-restart loop that ran continuously for ~2 days (4,477 relaunches, every ~20-45s — see log below). Every keybinding that opens an Omarchy menu (SUPER+SPACE, SUPER+K, etc., including the keybindings-help menu itself) eventually stopped working entirely, because the loop filled $XDG_RUNTIME_DIR (a 1.6G tmpfs) with 4,475 leftover quickshell/by-id/<id>/ log directories (1.5G). Once full, Quickshell couldn't write its own log or serve IPC calls (omarchy-shell <target> <method> → "omarchy-shell is not running").
Root cause (from the journal, see excerpt below)
- The shell ran normally for over an hour (
lock-requested/lock-pending: screen-stabilizingcycling normally, PID 7094). - Then a screen event produced a placeholder "FALLBACK" Wayland output not backed by a real screen (
Layershell screen does not correspond to a real screen), and Hyprland reported it removed (Got removal for monitor "FALLBACK" which was not previously tracked). - This triggered
The Wayland connection experienced a fatal error: Invalid argument, and Quickshell exited via Qt's_exit()(status 255) — no signal, soomarchy-crash-watchnever reported it as a crash. - Hyprland's
LOCKsolitaryBlockedByblocker on the monitor is (peromarchy-hyprland-session-locked's own comment) never cleared by an abnormal client exit, so it stays stuck. - Every relaunch's
strandedLockCheckProc(inplugins/lock/Service.qml) sees that stale "locked" state viaomarchy-hyprland-session-locked, treats it as a stranded lock (lock-stranded: recovering), and tries to recreate a lock surface — which hits the same FALLBACK-screen condition and crashes again. Indefinitely. omarchy-launch-shell's safety net (Giving up on the Omarchy shell after $attempts relaunches in under a minute) never triggers at this crash cadence: its 60s sliding window resets before 5 attempts accumulate whenever crashes are spaced more than 12s apart (they're ~20-45s apart here), so it loops forever instead of giving up.- Each crash leaves its
by-id/<instance>log directory behind uncleaned, slowly filling the runtime tmpfs until Quickshell can't function at all.
Impact
The entire Omarchy menu system (bar, keybinding popups, omarchy-menu-*) silently stops working, with no crash notification, until a user notices and manually kills+restarts the shell and clears the runtime directory.
Suggested fixes (any of these would help)
- Guard the
strandedLock/requestSessionLockpath inplugins/lock/Service.qmlagainst attempting lock-surface creation on a screen not backed by a real Wayland output. - Clear the stale
LOCKsolitaryBlockedByflag once its owning client is confirmed dead, rather than leaving it stuck indefinitely (in Hyprland itself, or by havingomarchy-hyprland-session-lockedaccount for it). - Fix the give-up window in
omarchy-launch-shell: track attempts over a longer/rolling window (e.g. 5 attempts in 5 minutes) instead of one that resets before fast repeat-crashes accumulate. - Have the launcher prune its own
by-idruntime directories on each launch, so a crash loop — whatever the cause — can't fill the tmpfs.
Log excerpt (first crash + one full repeat cycle, journal -t omarchy-shell, noise-filtered)
Aug 31 11:54:29 host omarchy-shell[1332]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml"
Aug 31 11:54:29 host omarchy-shell[1332]: INFO: Shell ID: "c0240dfe8c8e8a421e1f8db23a03fc60" Path ID "c0240dfe8c8e8a421e1f8db23a03fc60"
Aug 31 11:56:05 host omarchy-shell[4228]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml"
Aug 31 11:56:05 host omarchy-shell[4228]: INFO: Shell ID: "c0240dfe8c8e8a421e1f8db23a03fc60" Path ID "c0240dfe8c8e8a421e1f8db23a03fc60"
Aug 31 11:57:57 host omarchy-shell[7094]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml"
Aug 31 11:57:57 host omarchy-shell[7094]: INFO: Shell ID: "c0240dfe8c8e8a421e1f8db23a03fc60" Path ID "c0240dfe8c8e8a421e1f8db23a03fc60"
Aug 31 12:40:43 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-requested
Aug 31 12:40:43 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing
Aug 31 12:41:54 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-requested
Aug 31 12:41:54 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing
Aug 31 12:43:35 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-requested
Aug 31 12:43:35 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing
Aug 31 13:07:25 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-requested
Aug 31 13:07:25 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing
Aug 31 13:07:46 host omarchy-shell[7094]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick.
Aug 31 13:07:46 host omarchy-shell[7094]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick.
Aug 31 13:07:46 host omarchy-shell[7094]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick.
Aug 31 13:07:46 host omarchy-shell[7094]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick.
Aug 31 13:07:47 host omarchy-shell[7094]: WARN quickshell.hyprland.ipc: Got removal for monitor "FALLBACK" which was not previously tracked.
Aug 31 13:07:47 host omarchy-shell[7094]: WARN: The Wayland connection experienced a fatal error: Invalid argument
Aug 31 13:07:47 host omarchy-shell[293466]: Omarchy shell exited with status 255; relaunching.
Aug 31 13:07:48 host omarchy-shell[293708]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml"
Aug 31 13:07:48 host omarchy-shell[293708]: INFO: Shell ID: "c0240dfe8c8e8a421e1f8db23a03fc60" Path ID "c0240dfe8c8e8a421e1f8db23a03fc60"
Aug 31 13:07:48 host omarchy-shell[293708]: DEBUG qml: omarchy lock ... lock-stranded: recovering
Aug 31 13:07:48 host omarchy-shell[293708]: DEBUG qml: omarchy lock ... lock-requested
Aug 31 13:07:48 host omarchy-shell[293708]: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing
Aug 31 13:08:09 host omarchy-shell[293708]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick.
Aug 31 13:08:09 host omarchy-shell[293708]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick.
Aug 31 13:08:09 host omarchy-shell[293708]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick.
Aug 31 13:08:09 host omarchy-shell[293708]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick.
Aug 31 13:08:10 host omarchy-shell[293708]: WARN quickshell.hyprland.ipc: Got removal for monitor "FALLBACK" which was not previously tracked.
Aug 31 13:08:10 host omarchy-shell[293708]: WARN: The Wayland connection experienced a fatal error: Invalid argument
Aug 31 13:08:10 host omarchy-shell[298070]: Omarchy shell exited with status 255; relaunching.
Aug 31 13:08:11 host omarchy-shell[298318]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml"This exact lock-stranded → FALLBACK screen → fatal Wayland error → exit 255 → relaunch cycle then repeated roughly every 20-45s continuously from Aug 31 13:07 through Sep 2 10:13 (4,477 total relaunches) until the shell was manually killed and the runtime directory cleared. Hostname/PIDs anonymized above; happy to provide the full raw journal privately if useful.
Not reliably reproducible on demand — it followed a screen/output event during normal use and then self-sustained.
View raw text
## Environment - omarchy 4.0.2-1 - hyprland 0.56.2-1 - quickshell 0.3.1-1 - Single monitor: HDMI-A-1 (Acer ED270R, 1920x1080@60) - Arch Linux ## Summary `omarchy-shell` (Quickshell) entered a crash-restart loop that ran continuously for ~2 days (4,477 relaunches, every ~20-45s — see log below). Every keybinding that opens an Omarchy menu (`SUPER+SPACE`, `SUPER+K`, etc., including the keybindings-help menu itself) eventually stopped working entirely, because the loop filled `$XDG_RUNTIME_DIR` (a 1.6G tmpfs) with 4,475 leftover `quickshell/by-id/<id>/` log directories (1.5G). Once full, Quickshell couldn't write its own log or serve IPC calls (`omarchy-shell <target> <method>` → "omarchy-shell is not running"). ## Root cause (from the journal, see excerpt below) 1. The shell ran normally for over an hour (`lock-requested` / `lock-pending: screen-stabilizing` cycling normally, PID 7094). 2. Then a screen event produced a placeholder "FALLBACK" Wayland output not backed by a real screen (`Layershell screen does not correspond to a real screen`), and Hyprland reported it removed (`Got removal for monitor "FALLBACK" which was not previously tracked`). 3. This triggered `The Wayland connection experienced a fatal error: Invalid argument`, and Quickshell exited via Qt's `_exit()` (status 255) — no signal, so `omarchy-crash-watch` never reported it as a crash. 4. Hyprland's `LOCK` `solitaryBlockedBy` blocker on the monitor is (per `omarchy-hyprland-session-locked`'s own comment) never cleared by an abnormal client exit, so it stays stuck. 5. Every relaunch's `strandedLockCheckProc` (in `plugins/lock/Service.qml`) sees that stale "locked" state via `omarchy-hyprland-session-locked`, treats it as a **stranded lock** (`lock-stranded: recovering`), and tries to recreate a lock surface — which hits the same FALLBACK-screen condition and crashes again. Indefinitely. 6. `omarchy-launch-shell`'s safety net (`Giving up on the Omarchy shell after $attempts relaunches in under a minute`) never triggers at this crash cadence: its 60s sliding window resets before 5 attempts accumulate whenever crashes are spaced more than 12s apart (they're ~20-45s apart here), so it loops forever instead of giving up. 7. Each crash leaves its `by-id/<instance>` log directory behind uncleaned, slowly filling the runtime tmpfs until Quickshell can't function at all. ## Impact The entire Omarchy menu system (bar, keybinding popups, `omarchy-menu-*`) silently stops working, with no crash notification, until a user notices and manually kills+restarts the shell and clears the runtime directory. ## Suggested fixes (any of these would help) - Guard the `strandedLock`/`requestSessionLock` path in `plugins/lock/Service.qml` against attempting lock-surface creation on a screen not backed by a real Wayland output. - Clear the stale `LOCK` `solitaryBlockedBy` flag once its owning client is confirmed dead, rather than leaving it stuck indefinitely (in Hyprland itself, or by having `omarchy-hyprland-session-locked` account for it). - Fix the give-up window in `omarchy-launch-shell`: track attempts over a longer/rolling window (e.g. 5 attempts in 5 minutes) instead of one that resets before fast repeat-crashes accumulate. - Have the launcher prune its own `by-id` runtime directories on each launch, so a crash loop — whatever the cause — can't fill the tmpfs. ## Log excerpt (first crash + one full repeat cycle, journal `-t omarchy-shell`, noise-filtered) ``` Aug 31 11:54:29 host omarchy-shell[1332]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml" Aug 31 11:54:29 host omarchy-shell[1332]: INFO: Shell ID: "c0240dfe8c8e8a421e1f8db23a03fc60" Path ID "c0240dfe8c8e8a421e1f8db23a03fc60" Aug 31 11:56:05 host omarchy-shell[4228]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml" Aug 31 11:56:05 host omarchy-shell[4228]: INFO: Shell ID: "c0240dfe8c8e8a421e1f8db23a03fc60" Path ID "c0240dfe8c8e8a421e1f8db23a03fc60" Aug 31 11:57:57 host omarchy-shell[7094]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml" Aug 31 11:57:57 host omarchy-shell[7094]: INFO: Shell ID: "c0240dfe8c8e8a421e1f8db23a03fc60" Path ID "c0240dfe8c8e8a421e1f8db23a03fc60" Aug 31 12:40:43 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-requested Aug 31 12:40:43 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing Aug 31 12:41:54 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-requested Aug 31 12:41:54 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing Aug 31 12:43:35 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-requested Aug 31 12:43:35 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing Aug 31 13:07:25 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-requested Aug 31 13:07:25 host omarchy-shell[7094]: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing Aug 31 13:07:46 host omarchy-shell[7094]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick. Aug 31 13:07:46 host omarchy-shell[7094]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick. Aug 31 13:07:46 host omarchy-shell[7094]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick. Aug 31 13:07:46 host omarchy-shell[7094]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick. Aug 31 13:07:47 host omarchy-shell[7094]: WARN quickshell.hyprland.ipc: Got removal for monitor "FALLBACK" which was not previously tracked. Aug 31 13:07:47 host omarchy-shell[7094]: WARN: The Wayland connection experienced a fatal error: Invalid argument Aug 31 13:07:47 host omarchy-shell[293466]: Omarchy shell exited with status 255; relaunching. Aug 31 13:07:48 host omarchy-shell[293708]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml" Aug 31 13:07:48 host omarchy-shell[293708]: INFO: Shell ID: "c0240dfe8c8e8a421e1f8db23a03fc60" Path ID "c0240dfe8c8e8a421e1f8db23a03fc60" Aug 31 13:07:48 host omarchy-shell[293708]: DEBUG qml: omarchy lock ... lock-stranded: recovering Aug 31 13:07:48 host omarchy-shell[293708]: DEBUG qml: omarchy lock ... lock-requested Aug 31 13:07:48 host omarchy-shell[293708]: DEBUG qml: omarchy lock ... lock-pending: screen-stabilizing Aug 31 13:08:09 host omarchy-shell[293708]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick. Aug 31 13:08:09 host omarchy-shell[293708]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick. Aug 31 13:08:09 host omarchy-shell[293708]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick. Aug 31 13:08:09 host omarchy-shell[293708]: WARN: Layershell screen does not correspond to a real screen. Letting the compositor pick. Aug 31 13:08:10 host omarchy-shell[293708]: WARN quickshell.hyprland.ipc: Got removal for monitor "FALLBACK" which was not previously tracked. Aug 31 13:08:10 host omarchy-shell[293708]: WARN: The Wayland connection experienced a fatal error: Invalid argument Aug 31 13:08:10 host omarchy-shell[298070]: Omarchy shell exited with status 255; relaunching. Aug 31 13:08:11 host omarchy-shell[298318]: INFO: Launching config: "/usr/share/omarchy/shell/shell.qml" ``` This exact `lock-stranded → FALLBACK screen → fatal Wayland error → exit 255 → relaunch` cycle then repeated roughly every 20-45s continuously from Aug 31 13:07 through Sep 2 10:13 (4,477 total relaunches) until the shell was manually killed and the runtime directory cleared. Hostname/PIDs anonymized above; happy to provide the full raw journal privately if useful. Not reliably reproducible on demand — it followed a screen/output event during normal use and then self-sustained.
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 (lock)
The outcome (valid, duplicate, not a bug, …) is not decided yet.