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.
SUPER+J (Toggle window split) raises "Runtime error in Lua: no such layoutmsg for scrolling" on scrolling-layout workspaces
Reported by jc-9 · filed Oct 10, 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
Bug report: SUPER+J raises Lua runtime error on scrolling-layout workspaces
Title: SUPER+J (Toggle window split) raises "Runtime error in Lua: no such layoutmsg for scrolling" on scrolling-layout workspaces
System details
Intel Core i5-8365U, Intel UHD Graphics 620, Lenovo ThinkPad T490, Omarchy 4.0.4-1, Hyprland 0.56.2 (Lua config)
What's wrong?
Pressing SUPER+J ("Toggle window split") on a workspace whose layout is scrolling pops an error notification:
Runtime error in Lua: no such layoutmsg for scrolling
SUPER+L ("Toggle workspace layout", omarchy-hyprland-workspace-layout-toggle) deliberately puts workspaces on the scrolling layout and persists it to ~/.local/state/omarchy/workspace-layouts/<id>.lua. SUPER+J then hits the error — two stock default bindings combining into a runtime error.
Steps to recreate:
- Press SUPER+L on any workspace -> notification "Workspace layout set to scrolling"
- Press SUPER+J -> error notification "Runtime error in Lua: no such layoutmsg for scrolling"
Deterministic repro without the keybinding (workspace 1 is on scrolling here):
$ hyprctl activeworkspace -j | jq '{id, tiledLayout}'
{
"id": 1,
"tiledLayout": "scrolling",
"name": "1"
}
$ hyprctl eval 'hl.dispatch(hl.dsp.layout("togglesplit"))'
error: =[C]:-1: no such layoutmsg for scrolling
Root cause: SUPER+J is bound unconditionally to a dwindle-only layoutmsg in /usr/share/omarchy/default/hypr/bindings/tiling.lua:
o.bind("SUPER + J", "Toggle window split", hl.dsp.layout("togglesplit"))
togglesplit doesn't exist for the scrolling layout, so the dispatch raises a Lua runtime error that surfaces as a desktop notification.
Expected: a clean no-op (or a friendly "not available on this layout" note). Possible fix: guard the binding against the active workspace layout, or make a failed hl.dsp.layout dispatch degrade to a silent no-op instead of raising.
Full omarchy-debug --no-sudo --print output is in omarchy-debug.log in this package (4592 lines; key excerpt below).
omarchy-debug excerpt
Date: Sat Oct 10 08:06:15 AM CDT 2026
Hostname: omarchy
Omarchy Package: omarchy 4.0.4-1
Desktop: Hyprland v 0.56.2, vt 2, dm SDDM, Distro Omarchy
Machine: LENOVO ThinkPad T490 (20N3S5XF01)
CPU: Intel Core i5-8365U (8) @ 4.100GHz
GPU: Intel WhiskeyLake-U GT2 [UHD Graphics 620] (driver i915)
View raw text
# Bug report: SUPER+J raises Lua runtime error on scrolling-layout workspaces
Title: SUPER+J (Toggle window split) raises "Runtime error in Lua: no such layoutmsg for scrolling" on scrolling-layout workspaces
## System details
Intel Core i5-8365U, Intel UHD Graphics 620, Lenovo ThinkPad T490, Omarchy 4.0.4-1, Hyprland 0.56.2 (Lua config)
## What's wrong?
Pressing SUPER+J ("Toggle window split") on a workspace whose layout is `scrolling` pops an error notification:
> Runtime error in Lua: no such layoutmsg for scrolling
SUPER+L ("Toggle workspace layout", `omarchy-hyprland-workspace-layout-toggle`) deliberately puts workspaces on the scrolling layout and persists it to `~/.local/state/omarchy/workspace-layouts/<id>.lua`. SUPER+J then hits the error — two stock default bindings combining into a runtime error.
Steps to recreate:
1. Press SUPER+L on any workspace -> notification "Workspace layout set to scrolling"
2. Press SUPER+J -> error notification "Runtime error in Lua: no such layoutmsg for scrolling"
Deterministic repro without the keybinding (workspace 1 is on scrolling here):
$ hyprctl activeworkspace -j | jq '{id, tiledLayout}'
{
"id": 1,
"tiledLayout": "scrolling",
"name": "1"
}
$ hyprctl eval 'hl.dispatch(hl.dsp.layout("togglesplit"))'
error: =[C]:-1: no such layoutmsg for scrolling
Root cause: SUPER+J is bound unconditionally to a dwindle-only layoutmsg in `/usr/share/omarchy/default/hypr/bindings/tiling.lua`:
o.bind("SUPER + J", "Toggle window split", hl.dsp.layout("togglesplit"))
`togglesplit` doesn't exist for the scrolling layout, so the dispatch raises a Lua runtime error that surfaces as a desktop notification.
Expected: a clean no-op (or a friendly "not available on this layout" note). Possible fix: guard the binding against the active workspace layout, or make a failed `hl.dsp.layout` dispatch degrade to a silent no-op instead of raising.
Full `omarchy-debug --no-sudo --print` output is in `omarchy-debug.log` in this package (4592 lines; key excerpt below).
### omarchy-debug excerpt
Date: Sat Oct 10 08:06:15 AM CDT 2026
Hostname: omarchy
Omarchy Package: omarchy 4.0.4-1
Desktop: Hyprland v 0.56.2, vt 2, dm SDDM, Distro Omarchy
Machine: LENOVO ThinkPad T490 (20N3S5XF01)
CPU: Intel Core i5-8365U (8) @ 4.100GHz
GPU: Intel WhiskeyLake-U GT2 [UHD Graphics 620] (driver i915)
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-10 13:22 UTC