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.
default/hypr/apps/localsend.lua rule doesn't match in Hyprland 0.56 — LocalSend opens tiled and clicks break
Reported by fieldnote-ops · filed Aug 19, 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
Summary
The shipped LocalSend window rule in default/hypr/apps/localsend.lua does not match on Hyprland 0.56, so LocalSend opens tiled instead of floating — and while tiled, mouse clicks on buttons do nothing (hover works, press events never reach the app). The app is unusable until the window is floated.
Steps to reproduce
- Fresh Omarchy install, Wayland/Hyprland session (Hyprland 0.56.2).
- Launch LocalSend (1.18.1, pacman).
- Window opens tiled (floating: false), despite the shipped rule:
-- /usr/share/omarchy/default/hypr/apps/localsend.lua
o.window("(Share|localsend)", { float = true, center = true })- Click any button in the window (e.g. receive a text message, then click its "Copy" button). Hover reacts, click does nothing.
- Toggle the window floating (SUPER+T) → the same clicks work fine.
Root cause (hypothesis)
The class regex (Share|localsend) is unanchored. The window's class is org.localsend.localsend_app, which contains the substring localsend, so under substring regex semantics the rule should match — it does not.
Every other shipped string rule uses anchors, e.g.:
o.window("^(1[p|P]assword)$", ...) -- apps/1password.lua
o.window("^(Bitwarden)$", ...) -- apps/bitwarden.lualocalsend.lua appears to be the only unanchored string rule. Hyprland 0.56's hl.window_rule class matching seems to require a full-match (anchored) regex.
Verification
Adding an anchored rule in the user config fixes it — the window floats on launch and clicks work:
o.window("^org\\.localsend\\.localsend_app$", { float = true, center = true })(Confirmed: hyprctl clients reports floating: true for the relaunched window.)
Note: LocalSend 1.18.0 switched Linux windows from the GTK3 headerbar to native SSD decorations — likely why tiled hit-testing breaks (press events offset vs. content). Worth checking whether the fix belongs in the omarchy rule, the LocalSend window class, or both.
Environment
- Omarchy 4.0.0-1
- Hyprland 0.56.2 (v0.56.2, efb5099)
- LocalSend 1.18.1-1 (pacman)
- Arch Linux, kernel 7.1.8-arch1-3, x86_64
- Intel Core Ultra 7 155H / Intel Arc Graphics (integrated), Wayland session
View raw text
## Summary
The shipped LocalSend window rule in `default/hypr/apps/localsend.lua` does not match on Hyprland 0.56, so LocalSend opens **tiled** instead of floating — and while tiled, mouse **clicks on buttons do nothing** (hover works, press events never reach the app). The app is unusable until the window is floated.
## Steps to reproduce
1. Fresh Omarchy install, Wayland/Hyprland session (Hyprland 0.56.2).
2. Launch LocalSend (1.18.1, pacman).
3. Window opens **tiled** (floating: false), despite the shipped rule:
```lua
-- /usr/share/omarchy/default/hypr/apps/localsend.lua
o.window("(Share|localsend)", { float = true, center = true })
```
4. Click any button in the window (e.g. receive a text message, then click its "Copy" button). Hover reacts, click does nothing.
5. Toggle the window floating (SUPER+T) → the same clicks work fine.
## Root cause (hypothesis)
The class regex `(Share|localsend)` is unanchored. The window's class is `org.localsend.localsend_app`, which **contains** the substring `localsend`, so under substring regex semantics the rule should match — it does not.
Every other shipped string rule uses anchors, e.g.:
```lua
o.window("^(1[p|P]assword)$", ...) -- apps/1password.lua
o.window("^(Bitwarden)$", ...) -- apps/bitwarden.lua
```
`localsend.lua` appears to be the only unanchored string rule. Hyprland 0.56's `hl.window_rule` class matching seems to require a full-match (anchored) regex.
## Verification
Adding an anchored rule in the user config fixes it — the window floats on launch and clicks work:
```lua
o.window("^org\\.localsend\\.localsend_app$", { float = true, center = true })
```
(Confirmed: `hyprctl clients` reports `floating: true` for the relaunched window.)
Note: LocalSend 1.18.0 switched Linux windows from the GTK3 headerbar to native SSD decorations — likely why tiled hit-testing breaks (press events offset vs. content). Worth checking whether the fix belongs in the omarchy rule, the LocalSend window class, or both.
## Environment
- Omarchy 4.0.0-1
- Hyprland 0.56.2 (v0.56.2, efb5099)
- LocalSend 1.18.1-1 (pacman)
- Arch Linux, kernel 7.1.8-arch1-3, x86_64
- Intel Core Ultra 7 155H / Intel Arc Graphics (integrated), Wayland session
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 04:46 UTC