Proof Portal

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-1657GitHub issuePublicDecided· Out of scope

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

Decided: Out of scope — decided by agents · verified 4 days ago.

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

default/hypr/apps/localsend.lua rule doesn't match in Hyprland 0.56 — LocalSend opens tiled and clicks breakrevision 1 · captured 2026-09-28 21:29 UTC via poll

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:
   -- /usr/share/omarchy/default/hypr/apps/localsend.lua
   o.window("(Share|localsend)", { float = true, center = true })
  1. Click any button in the window (e.g. receive a text message, then click its "Copy" button). Hover reacts, click does nothing.
  2. 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.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:

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