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.
omarchy-hyprland-workspace-layout-toggle writes a persistent workspace rule that permanently shadows a user-configured global layout, with no way to clear it
Reported by mgdweb · filed Aug 20, 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-version 4.0.0-1, Hyprland 0.56.2
What's wrong?
Summary
A user who sets a non-default global layout in ~/.config/hypr/looknfeel.lua — e.g. general.layout = "master" — finds that layout silently and permanently overridden on any workspace where SUPER + L has been pressed, with no supported way to undo it.
Mechanism
omarchy-hyprland-workspace-layout-toggle writes a per-workspace rule to $HOME/.local/state/omarchy/workspace-layouts/<id>.lua:
hl.workspace_rule({ workspace = "<id>", layout = "<dwindle|scrolling>" })
default/hypr/workspace-layouts.lua loads that directory on every config load. Because a workspace rule takes precedence over general.layout, the stale rule reapplies on each reload, defeating the user's global setting indefinitely.
Steps to reproduce
Set general.layout = "master" in ~/.config/hypr/looknfeel.lua
Press SUPER + L once on any workspace
Reload, or reboot
The workspace returns in dwindle or scrolling, never master
Not reversible via the toggle. The script's case statement maps dwindle → scrolling and everything else → dwindle. Master is not in the cycle, so no number of presses returns the user to their configured layout. Any global layout other than those two is a one-way trip.
Survives config restore. The state lives outside ~/.config/hypr, so restoring config backups — the obvious user remedy — has no effect. This makes the cause very difficult to identify; in my case it took reading the script source to work out what was happening.
Silent. Nothing indicates that a persistent per-workspace override now exists, or where it lives. The notification reports the layout was set, not that a rule was written to disk.
I came across this issue when upgrading my omarchy machine. I have a large monitor and prefer the master layout as detailed below
OS: Omarchy x86_64
Kernel: Linux 7.1.8-arch1-3
CPU: AMD Ryzen 7 8845HS (16) @ 5.10 GHz
GPU: AMD Radeon 780M Graphics [Integrated]
Memory: 5.21 GiB / 27.18 GiB (19%)
Disk (/): 96.46 GiB / 929.50 GiB (10%) - btrfs
Display (P40w-20): 5120x2160 in 40", 75 Hz [External]~/.config/hypr
> cat looknfeel.lua
hl.config({
general = {
-- Use master layout (one main window + side stack)
layout = "master",
},
})
hl.config({
master = {
-- Master window factor: 45% of screen width
mfact = 0.45,
-- Center orientation for master window
orientation = "center",
},
})
hl.config({
decoration = {
-- Use round window corners
rounding = 8,
},
})
hl.config({
layout = {
-- Prevent single window from filling entire screen
-- Constrain to 16:9 aspect ratio (adjust as needed)
single_window_aspect_ratio = { 1, 1 },
},
})~/.config/hypr
❯ cat monitors.lua
-- configured by mgd 2026-08-20 14:12
local omarchy_gdk_scale = 1
local omarchy_monitor_scale = 1
hl.env("GDK_SCALE", tostring(omarchy_gdk_scale))
hl.monitor({ output = "DP-1", mode = "[email protected]", position = "auto", scale = omarchy_monitor_scale })
~/.config/hyprMonitor DP-1 (ID 0):
[email protected] at 0x0
description: Lenovo Group Limited P40w-20 V909503C
make: Lenovo Group Limited
model: P40w-20
physical size (mm): 930x390
serial: V909503C
active workspace: 1 (1)
special workspace: 0 ()
reserved: 0 48 0 0
scale: 1
transform: 0
focused: yes
dpmsStatus: 1
vrr: false
solitary: 0
solitaryBlockedBy: windowed mode,missing candidate
activelyTearing: false
tearingBlockedBy: next frame is not torn,user settings,missing candidate
directScanoutTo: 0
directScanoutBlockedBy: user settings,missing candidate
disabled: false
currentFormat: XRGB8888
mirrorOf: none
availableModes: [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]
colorManagementPreset: srgb
sdrBrightness: 1
sdrSaturation: 1
sdrMinLuminance: 0.2
sdrMaxLuminance: 80
hardwareCursorsInUse: trueView raw text
### System details
omarchy-version 4.0.0-1, Hyprland 0.56.2
### What's wrong?
**Summary**
A user who sets a non-default global layout in ~/.config/hypr/looknfeel.lua — e.g. general.layout = "master" — finds that layout silently and permanently overridden on any workspace where SUPER + L has been pressed, with no supported way to undo it.
**Mechanism**
omarchy-hyprland-workspace-layout-toggle writes a per-workspace rule to $HOME/.local/state/omarchy/workspace-layouts/<id>.lua:
hl.workspace_rule({ workspace = "<id>", layout = "<dwindle|scrolling>" })
default/hypr/workspace-layouts.lua loads that directory on every config load. Because a workspace rule takes precedence over general.layout, the stale rule reapplies on each reload, defeating the user's global setting indefinitely.
**Steps to reproduce**
Set general.layout = "master" in ~/.config/hypr/looknfeel.lua
Press SUPER + L once on any workspace
Reload, or reboot
The workspace returns in dwindle or scrolling, never master
Not reversible via the toggle. The script's case statement maps dwindle → scrolling and everything else → dwindle. Master is not in the cycle, so no number of presses returns the user to their configured layout. Any global layout other than those two is a one-way trip.
Survives config restore. The state lives outside ~/.config/hypr, so restoring config backups — the obvious user remedy — has no effect. This makes the cause very difficult to identify; in my case it took reading the script source to work out what was happening.
Silent. Nothing indicates that a persistent per-workspace override now exists, or where it lives. The notification reports the layout was set, not that a rule was written to disk.
I came across this issue when upgrading my omarchy machine. I have a large monitor and prefer the master layout as detailed below
```
OS: Omarchy x86_64
Kernel: Linux 7.1.8-arch1-3
CPU: AMD Ryzen 7 8845HS (16) @ 5.10 GHz
GPU: AMD Radeon 780M Graphics [Integrated]
Memory: 5.21 GiB / 27.18 GiB (19%)
Disk (/): 96.46 GiB / 929.50 GiB (10%) - btrfs
Display (P40w-20): 5120x2160 in 40", 75 Hz [External]
```
```
~/.config/hypr
> cat looknfeel.lua
hl.config({
general = {
-- Use master layout (one main window + side stack)
layout = "master",
},
})
hl.config({
master = {
-- Master window factor: 45% of screen width
mfact = 0.45,
-- Center orientation for master window
orientation = "center",
},
})
hl.config({
decoration = {
-- Use round window corners
rounding = 8,
},
})
hl.config({
layout = {
-- Prevent single window from filling entire screen
-- Constrain to 16:9 aspect ratio (adjust as needed)
single_window_aspect_ratio = { 1, 1 },
},
})
```
```
~/.config/hypr
❯ cat monitors.lua
-- configured by mgd 2026-08-20 14:12
local omarchy_gdk_scale = 1
local omarchy_monitor_scale = 1
hl.env("GDK_SCALE", tostring(omarchy_gdk_scale))
hl.monitor({ output = "DP-1", mode = "[email protected]", position = "auto", scale = omarchy_monitor_scale })
~/.config/hypr
```
```❯ hyprctl monitors
Monitor DP-1 (ID 0):
[email protected] at 0x0
description: Lenovo Group Limited P40w-20 V909503C
make: Lenovo Group Limited
model: P40w-20
physical size (mm): 930x390
serial: V909503C
active workspace: 1 (1)
special workspace: 0 ()
reserved: 0 48 0 0
scale: 1
transform: 0
focused: yes
dpmsStatus: 1
vrr: false
solitary: 0
solitaryBlockedBy: windowed mode,missing candidate
activelyTearing: false
tearingBlockedBy: next frame is not torn,user settings,missing candidate
directScanoutTo: 0
directScanoutBlockedBy: user settings,missing candidate
disabled: false
currentFormat: XRGB8888
mirrorOf: none
availableModes: [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]
colorManagementPreset: srgb
sdrBrightness: 1
sdrSaturation: 1
sdrMinLuminance: 0.2
sdrMaxLuminance: 80
hardwareCursorsInUse: true
```
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 08:12 UTC