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.
Hyprland crashes when dragging windows (CDwindleAlgorithm::movedTarget)
Reported by mat888 · filed Sep 9, 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?
- 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
System details
Omarchy 4.0.2 Hyprland 0.56.2 Kernel: 7.1.9-arch1-2 GPU: AMD Radeon Navi 31 (RX 7900 XT/XTX/GRE family) + Raphael iGPU Wayland / Hyprland session
What's wrong?
Hyprland occasionally crashes while a window is being dragged. Every observed occurrence of this crash pattern has happened during window dragging.
The crash on September 7: The systemd coredump shows Hyprland failing in the dwindle-layout window-drag/floating transition:
#6 Layout::Tiled::CDwindleAlgorithm::movedTarget
#7 Layout::CAlgorithm::moveTarget
#8 Layout::CAlgorithm::setFloating
#9 Layout::CSpace::toggleTargetFloating
#10 Layout::CLayoutManager::changeFloatingMode
#11 Layout::Supplementary::CDragStateController::dragEnd
#13 Layout::Supplementary::CDragStateController::dragBegin
#14 Layout::CLayoutManager::beginDragTarget
#16 Config::Actions::mouseA separate Hyprland crash on September 4, also on 0.56.2, produced essentially the same CDwindleAlgorithm::movedTarget / floating-state stack.
The apparent Firefox crash afterward is secondary. Once Hyprland crashes, Firefox loses its Wayland connection and reports:
(hyprland) Error reading events from display: Broken pipe
So Firefox does not appear to be the initiating failure.
Reproduction
The failure is intermittent rather than deterministic:
Run a normal Omarchy/Hyprland session.
Drag a window using the standard Hyprland mouse-drag binding.
Occasionally Hyprland crashes during the drag operation.
The failure appears related to this upstream Hyprland 0.56.x interactive-drag/dwindle issue:
https://github.com/hyprwm/Hyprland/discussions/15856
The stack is not identical: that report reaches CDwindleAlgorithm::resizeTarget, while these crashes reach CDwindleAlgorithm::movedTarget. Both, however, occur during interactive dragging and involve the dwindle layout state.
Older crashes on this machine under Hyprland 0.54.0 also reached the closely related path:
CDwindleAlgorithm::movedTarget
→ CDwindleAlgorithm::addTarget
→ CAlgorithm::setFloating
→ CSpace::toggleTargetFloating
That may indicate a broader or older issue in the same drag/floating-state machinery rather than only the specific 0.56.x regression above.
omarchy-debug output can be attached with the issue.
Written with AI
View raw text
### System details Omarchy 4.0.2 Hyprland 0.56.2 Kernel: 7.1.9-arch1-2 GPU: AMD Radeon Navi 31 (RX 7900 XT/XTX/GRE family) + Raphael iGPU Wayland / Hyprland session ### What's wrong? Hyprland occasionally crashes while a window is being dragged. Every observed occurrence of this crash pattern has happened during window dragging. The crash on September 7: The systemd coredump shows Hyprland failing in the dwindle-layout window-drag/floating transition: ``` #6 Layout::Tiled::CDwindleAlgorithm::movedTarget #7 Layout::CAlgorithm::moveTarget #8 Layout::CAlgorithm::setFloating #9 Layout::CSpace::toggleTargetFloating #10 Layout::CLayoutManager::changeFloatingMode #11 Layout::Supplementary::CDragStateController::dragEnd #13 Layout::Supplementary::CDragStateController::dragBegin #14 Layout::CLayoutManager::beginDragTarget #16 Config::Actions::mouse ``` A separate Hyprland crash on September 4, also on 0.56.2, produced essentially the same CDwindleAlgorithm::movedTarget / floating-state stack. The apparent Firefox crash afterward is secondary. Once Hyprland crashes, Firefox loses its Wayland connection and reports: (hyprland) Error reading events from display: Broken pipe So Firefox does not appear to be the initiating failure. Reproduction The failure is intermittent rather than deterministic: Run a normal Omarchy/Hyprland session. Drag a window using the standard Hyprland mouse-drag binding. Occasionally Hyprland crashes during the drag operation. The failure appears related to this upstream Hyprland 0.56.x interactive-drag/dwindle issue: https://github.com/hyprwm/Hyprland/discussions/15856 The stack is not identical: that report reaches CDwindleAlgorithm::resizeTarget, while these crashes reach CDwindleAlgorithm::movedTarget. Both, however, occur during interactive dragging and involve the dwindle layout state. Older crashes on this machine under Hyprland 0.54.0 also reached the closely related path: CDwindleAlgorithm::movedTarget → CDwindleAlgorithm::addTarget → CAlgorithm::setFloating → CSpace::toggleTargetFloating That may indicate a broader or older issue in the same drag/floating-state machinery rather than only the specific 0.56.x regression above. omarchy-debug output can be attached with the issue. Written with AI
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 11:17 UTC