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.
Unplugging a monitor destroys overlay surfaces until the shell restarts
Reported by shawnyeager · filed Sep 30, 2026 · open at source · 3 revisions
This defect is tracked under R-2159. This report describes the same defect, so it is folded under it in the inbox.
Earliest report of this defect: R-2129 (filed Sep 30, 2026).
Decided by agents · verified· Oct 9, 2026
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?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Intel Core Ultra X7 358H, Intel Arc B390, Omarchy 4.0.0.r6691.g8b4eae6-1, Hyprland 0.56.2, Quickshell 0.3.1, kernel 7.2.5-4-omarchy. Outputs: eDP-1 (laptop) and DP-1 (ASUS PA27JCV).
What's wrong?
Super+Space shows nothing after the external monitor is unplugged and plugged back in. The same shell process is still running, and omarchy menu summon still returns ok, but hyprctl layers has no omarchy-menu surface on either output. The OSD dies the same way. The bar and the background come back.
This started with #13419. OverlayWindow keeps one layer surface for the life of the shell. When that surface's output goes away, Hyprland closes it. Quickshell handles zwlr_layer_surface_v1.closed by calling QWindow::close(), and because a layer shell window deletes its backing window when it becomes invisible, the overlay stays unmapped. The constant visible: true binding is not evaluated again. Per-screen windows are unaffected: their Variants rebuild them when Quickshell.screens changes.
What I recorded
The running shell (pid 3778386, started 2026-09-29 15:43) logged this on DP-1:
monitorremoved>>DP-1
monitorremovedv2>>1,DP-1,ASUSTek COMPUTER INC PA27JCV T5LMSV003436
closelayer>>omarchy-background
closelayer>>omarchy-menu
closelayer>>omarchy-osd
closelayer>>omarchy-bar
openlayer>>omarchy-bar
openlayer>>omarchy-backgroundDP-1 was added back after that. openlayer>>omarchy-bar happened again. openlayer>>omarchy-menu and openlayer>>omarchy-osd did not. With both outputs connected again, layers are:
- eDP-1:
omarchy-background,omarchy-bar, and the parked 1x1 clipboard, emoji, image-selector, and reminder surfaces - DP-1:
omarchy-background,omarchy-bar - neither output:
omarchy-menu,omarchy-osd
Expected
Unplugging a monitor, then plugging it back in, leaves Super+Space opening the menu on the focused output. The parked overlay surfaces should be mapped again, the way the bar and background already are.
Workaround
omarchy restart shell creates the surfaces again. The next unplug of the output an overlay last opened on kills them again.
Fix
#13792 remaps OverlayWindow after the compositor closes it. This report is that bug. #13562 is the separate case where the surface still exists but stays on the bottom layer after focus moves to the other monitor.
View raw text
### System details Intel Core Ultra X7 358H, Intel Arc B390, Omarchy 4.0.0.r6691.g8b4eae6-1, Hyprland 0.56.2, Quickshell 0.3.1, kernel 7.2.5-4-omarchy. Outputs: eDP-1 (laptop) and DP-1 (ASUS PA27JCV). ### What's wrong? Super+Space shows nothing after the external monitor is unplugged and plugged back in. The same shell process is still running, and `omarchy menu summon` still returns ok, but `hyprctl layers` has no `omarchy-menu` surface on either output. The OSD dies the same way. The bar and the background come back. This started with #13419. `OverlayWindow` keeps one layer surface for the life of the shell. When that surface's output goes away, Hyprland closes it. Quickshell handles `zwlr_layer_surface_v1.closed` by calling `QWindow::close()`, and because a layer shell window deletes its backing window when it becomes invisible, the overlay stays unmapped. The constant `visible: true` binding is not evaluated again. Per-screen windows are unaffected: their `Variants` rebuild them when `Quickshell.screens` changes. ### What I recorded The running shell (pid 3778386, started 2026-09-29 15:43) logged this on DP-1: ``` monitorremoved>>DP-1 monitorremovedv2>>1,DP-1,ASUSTek COMPUTER INC PA27JCV T5LMSV003436 closelayer>>omarchy-background closelayer>>omarchy-menu closelayer>>omarchy-osd closelayer>>omarchy-bar openlayer>>omarchy-bar openlayer>>omarchy-background ``` DP-1 was added back after that. `openlayer>>omarchy-bar` happened again. `openlayer>>omarchy-menu` and `openlayer>>omarchy-osd` did not. With both outputs connected again, layers are: - eDP-1: `omarchy-background`, `omarchy-bar`, and the parked 1x1 clipboard, emoji, image-selector, and reminder surfaces - DP-1: `omarchy-background`, `omarchy-bar` - neither output: `omarchy-menu`, `omarchy-osd` ### Expected Unplugging a monitor, then plugging it back in, leaves Super+Space opening the menu on the focused output. The parked overlay surfaces should be mapped again, the way the bar and background already are. ### Workaround `omarchy restart shell` creates the surfaces again. The next unplug of the output an overlay last opened on kills them again. ### Fix #13792 remaps `OverlayWindow` after the compositor closes it. This report is that bug. #13562 is the separate case where the surface still exists but stays on the bottom layer after focus moves to the other monitor.
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
- Duplicate ofR-2159Shell restart after an update leaves overlapping quickshell generations; menu keybind dies silently while IPC still answers· decided by agents · verified
- Related toR-12Menu (Super+Space) needs several presses to open after focus moves to another monitor· decided by agents · verified
- Fixed bypr/13903· confirmed
- Related PRpr/13809· confirmed
- Fixed bypr/13792· 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.